craftyguy

The skip1s app lets you backup and upload configuration on the remote, and I'm wondering if the remote has a limit to the number of times that backups like this can be uploaded to the remote. In other words, does the remote use some storage for config with a limited number of writes? Sometimes embedded storage only support a really low number (like 10s) of writes, it would be nice to know if the hw in this remote has a similar limitation.

Thanks for the response. Regarding Tauri, can you specify the newer version (1.5) somewhere? It should fix this bug I hit, unless there's some other new failure that looks the same. That's good news about Tauri supporting flatpak some day, I hope they make it happen. If there was a library or even just some very basic docs from you about how to communicate with the remote over USB (I assume HID?), then I bet other people would create alternative UIs for your remote that run natively on systems you don't want to support. The skip 1s is a really great-looking remote, at least the hardware is. The software required to use it has been really really (really) rough for me over the last year, it's easily the 1 thing I dislike about the Skip1s. Every time I want to change a button, I basically have to go on a multi-hour/day adventure like this to get the app running on my system. I'd honestly rather spend that time making a new open source app for this remote.

This error is from the shell in the container, not the host OS. I'm not able to run this at all on the host OS because AppImage dynamically links to glibc and I'm using a Linux distro that uses a different libc (musl). Normally I'd work around this by either 1) finding (or packaging) the app in Flatpak, or 2) running it manually in a Debian container. #1 seems hard to do since it would involve deconstructing your appimage thing and stuffing it into a flatpak, #2 is where I get the above failure. > Have you tried the release candidate? Yeah, it still fails, and the panic still references the same Tauri commit (9dcc2f9152472c1a). Which version of Tauri are you using? Did you happen to see the upstream Tauri bug I linked to earlier?

I have to run the skip 1s configuration app in a Debian 12 container because AppImage does terrible things for a package thing that claims to "run anywhere". Anyways, it fails with this panic message: [clayton@debian Downloads]$ ./skip-app_0.9.968_amd64.AppImage --appimage-extract-and-run Gtk-Message: 16:14:44.057: Failed to load module "canberra-gtk-module" Gtk-Message: 16:14:44.058: Failed to load module "canberra-gtk-module" Panicked: PanicInfo { payload: Any { .. }, message: Some(`APPDIR` or `APPIMAGE` environment variable found but this application was not detected as an AppImage; this might be a security issue.), location: Location { file: "/root/.cargo/git/checkouts/tauri-9dcc2f9152472c1a/8c5fcf4/core/tauri-utils/src/lib.rs", line: 205, col: 11 }, can_unwind: true, force_no_backtrace: fntalse } This Tauri bug mentions a similar failure that was apparently fixed in 1.5.0: https://github.com/tauri-apps/tauri/issues/7736 Are you using Tauri >=1.5.0 to package this app?

When using the FLIRC USB gen2 with the Skip 1s, I see that multiple presses are registered for 1 button click quite often. I suspect it's because the time between when a button is pressed and a button repeat is registered must be very short. I think that when a button is pressed, repeating shouldn't occur unless it has been pressed for some amount of time (e.g. 500 ms?) to prevent bouncing / unintentional repeating. Can this be configured somehow?

I also just discovered that these are missing in the Flirc / Kodi config in the Skip app, specifically the "home" button since I use that one quite often. I can see the json config for this "device" in the skip app after enabling admin mode, however I have no clue what the correct "code" might be to add this key to the config...

thanks a lot for the video, that was very helpful. I've been able to confirm that the config for the Denon DHT-S517 seems to be working!

Ya sorry, I'm really trying here, but either the app is very poorly laid out, or I'm having some significant UI issues running this "portable" appimage thing that prevent me from interacting / seeing things the way you intend. I'm not seeing the same button panel that you have in the user guide, and "draw a circle"... around what? recording.mp4

Ok added it (the UI textbox to add configs was locked at 1 line high, btw) I think the device type should be a "Soundbar", it's currently showing as "Audio, Misc" I added it to an activity, but toggling power to it does not show up in the activity summary, so there's no way to actually turn it on/off (I guess?)

Thanks. I can import this config by enabling the admin panel, and going to Config->Open Config file ? I tried doing that but clicking on "Open config file" does nothing for me, likely due to there being some significant UI rendering/usability issues (that I emailed you about)... Is there some other way I can import this into the app to try it?

Excellent!! I'm looking forward to trying it :) Yeah it's a Denon DHT-S517. Is there any more info you need about it?

I've tried all of the profiles under Audio->Denon, none seem to work for this particular model. Even the aptly named "DHT-S/T Series (Soundbar)" didn't work. I think this would probably be a lot easier on users if the app / remote had a "learning" mode, then we could create / share our own mappings instead of having to request them from you :)

It looks like this app is built with Tauri[1], which provides the build system for generating the appimage (I determined this by running 'strings' on the app's exe within the appimage). These seem to be linker errors, because there must(?) be some bug in Tauri's appimage packaging where some dependencies aren't included or detected properly at runtime, so the host libs are searched instead and it's not able to find some symbols presumably because it was (dynamically...) linked against some different version. appimage is really not a great portable format for these things... It also dynamically links against glibc (so, it requires glibc on the host), meaning it won't work on distros that don't use glibc. appimage also depends on FUSE, which may not be available on some distros/kernels. 1. https://github.com/tauri-apps/tauri

Ohhhh I thought you **had** gotten it to work (emphasis mine): Ok, so it seems like this may not be a permission issue then... In that case, we'll really need flirc's help... or access to the source code(...) so we can try to figure it out.

Did you do this via a udev rule or `chown /dev/something` ? If you used a udev rule, did you match on the usb subsystem or ?? If you used chown manually, what file did you change ownership on? I've tried several variations of the udev rule I posted earlier, including making *all* usb devices RW for a group my user is in, but nothing seems to work. For kicks, I used strace to figure out if there's an explicit open() for some device file that fails, but I wasn't able to see anything obvious. I don't have any more ideas for debugging this particular app, it's a blackbox. flirc folks: How can I help you figure this out? How are customers supposed to get support for this product?

Which specific device node under /dev did you change ownership for? As you can see in my udev rule above, I was setting it on /dev/hidraw*, but if the app is using something else (/dev/ttyUSB* or ??) then the udev rule could be adjusted easily to set permissions automatically Yes of course :) Ya in my experience flatpak is the least bad option for an "application bundle" distribution thing. Ideally the source for this application would be available so it could be provided in distro packaging and packaged as a flatpak (the two aren't mutually exclusive...)

Originally thought this might be a permission issue, since (in my Debian VM), `/dev/hidraw*` is owned by root. I added this udev rule to set group ownership of hidraw devices to 'plugdev': KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0644", GROUP="plugdev" Anyways, that wasn't enough to get it working for me. Next I fired up wireshark just to see if the app was even attempting to communicate with the remote, and I didn't see any host-->device traffic after starting the app. So my current theory is that there's still some permission issue that's preventing the app from writing to the device. But without the source code, only the flirc.tv folks can solve this :( Please consider releasing the source code for this app. It's currently a disaster to run/debug on Linux (appimage isn't actually all that portable)

When attempting to download the Linux version of the skip app, I am prompted for a username/password. The url is https://update.flirc.tv/skipapp/nightly/0.9.80.6117/SkipApp-0.9.80.6117-Nightly-x64.AppImage?=skipAppUpdate Also, is the source code for the app available for inspection / building locally?