clayton

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?