I was actually watching that issue previously and thought it was resolved 4.15?
Just downgraded to 4.13 like some folks in the thread suggested and thought it may have been the fix but sadly not, BT worked for about 2 minutes(perhaps related to my scan interval, or the length of time it takes the addon to autoboot) and then I get the same errors.
Thank you for the suggestion tho. It doesn’t really seem to be a problem with the addon specifically but a larger pi3 problem involving some conflict with bluetooth & usb devices, uart & baud rates & other things that are beyond me.
Hoping to pick up a pi4 next week so that might make this the last in a long line of pi3 bluetooth problems for me.
Thanks again for the addon!
This looks really interesting, thanks for sharing.
Currently have OG Hyperion running on a pi zero W attached to the back of the TV and fed by the Kodi add on from my HTPC so only need power up the wall.
This looks like it could be a simple way to get a grabber from my AVR to cover all sources to the HTPC that HA runs on and then use this to forward to the pi zero with no extra cables to run up the wall.
Tested the forwarding and all works nicely.
Just updating with the full log in case anyone smarter than me can shed some light…
Here’s the entries I see once I start the addon, at which point bluetooth fails:
[ 276.991423] retire_capture_urb: 23 callbacks suppressed
[ 1522.894467] hassio: port 10(veth0e48da2) entered blocking state
[ 1522.898766] hassio: port 10(veth0e48da2) entered disabled state
[ 1522.902842] device veth0e48da2 entered promiscuous mode
[ 1522.906440] audit: type=1700 audit(1604267578.779:172): dev=veth0e48da2 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
[ 1522.907015] IPv6: ADDRCONF(NETDEV_UP): veth0e48da2: link is not ready
[ 1522.913281] audit: type=1300 audit(1604267578.779:172): arch=40000028 syscall=290 per=800000 success=yes exit=40 a0=c a1=3aab260 a2=28 a3=0 items=0 ppid=1 pid=344 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dockerd" exe="/usr/bin/dockerd" subj==unconfined key=(null)
[ 1522.935797] audit: type=1327 audit(1604267578.779:172): proctitle=2F7573722F62696E2F646F636B657264002D480066643A2F2F002D2D73746F726167652D6472697665723D6F7665726C617932002D2D6C6F672D6472697665723D6A6F75726E616C64002D2D646174612D726F6F74002F6D6E742F646174612F646F636B6572
[ 1523.008123] audit: type=1325 audit(1604267578.889:173): table=nat family=2 entries=21
[ 1523.014860] audit: type=1300 audit(1604267578.889:173): arch=40000028 syscall=294 per=800000 success=yes exit=0 a0=4 a1=0 a2=40 a3=d53c10 items=0 ppid=344 pid=6936 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/usr/sbin/xtables-legacy-multi" subj==unconfined key=(null)
[ 1523.033311] audit: type=1327 audit(1604267578.889:173): proctitle=2F7573722F7362696E2F69707461626C6573002D2D77616974002D74006E6174002D4100444F434B4552002D7000746370002D6400302F30002D2D64706F7274003139343435002D6A00444E4154002D2D746F2D64657374696E6174696F6E003137322E33302E33332E343A31393434350000002D690068617373696F
[ 1523.048677] audit: type=1325 audit(1604267578.919:174): table=filter family=2 entries=33
[ 1523.056920] audit: type=1300 audit(1604267578.919:174): arch=40000028 syscall=294 per=800000 success=yes exit=0 a0=4 a1=0 a2=40 a3=de2818 items=0 ppid=344 pid=6938 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/usr/sbin/xtables-legacy-multi" subj==unconfined key=(null)
[ 1523.077588] audit: type=1327 audit(1604267578.919:174): proctitle=2F7573722F7362696E2F69707461626C6573002D2D77616974002D740066696C746572002D4100444F434B45520000002D690068617373696F002D6F0068617373696F002D7000746370002D64003137322E33302E33332E34002D2D64706F7274003139343435002D6A00414343455054
[ 1523.096053] audit: type=1325 audit(1604267578.939:175): table=nat family=2 entries=22
[ 1524.345898] eth0: renamed from veth6f6fb1c
[ 1524.405836] IPv6: ADDRCONF(NETDEV_CHANGE): veth0e48da2: link becomes ready
[ 1524.410681] hassio: port 10(veth0e48da2) entered blocking state
[ 1524.415053] hassio: port 10(veth0e48da2) entered forwarding state
[ 1528.521249] retire_capture_urb: 68 callbacks suppressed
[ 1533.532149] retire_capture_urb: 106 callbacks suppressed
[ 1535.933561] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1535.938268] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1535.943420] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1535.948096] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1537.853019] Bluetooth: hci0: command 0x0419 tx timeout
[ 1538.725397] retire_capture_urb: 133 callbacks suppressed
[ 1543.742247] retire_capture_urb: 166 callbacks suppressed
[ 1548.815267] retire_capture_urb: 110 callbacks suppressed
[ 1553.856145] retire_capture_urb: 164 callbacks suppressed
[ 1556.182588] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1556.186295] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1556.189679] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1557.933119] Bluetooth: hci0: command 0x0419 tx timeout
Those errors will repeat indefinitely for some time. If I stop the addon soon enough, bluetooth function returns and the logs stop with the following:
[ 1661.589613] hassio: port 10(veth0e48da2) entered disabled state
[ 1661.591536] veth6f6fb1c: renamed from eth0
[ 1661.716783] hassio: port 10(veth0e48da2) entered disabled state
[ 1661.722335] device veth0e48da2 left promiscuous mode
[ 1661.724607] hassio: port 10(veth0e48da2) entered disabled state
[ 1664.453636] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1664.455989] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1664.458216] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1664.460444] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1664.462487] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1704.953800] retire_capture_urb: 96 callbacks suppressed
If left running eventually the bluetooth logs cease, presumably timing out, and stopping the addon does not help, at which point a restart is required to regain bluetooth function.
This would appear to be hardware related. But also software 
I installed MotionEye and dug out a PS3 Eye camera I had lying around.
Summary of the troubleshooting -
-
- Hyperion addon & USB Grabber: As above, instant errors & device tracker failure.
-
- MotionEye & USB Grabber: Same errors, but less frequent. Bluetooth tracking still works although it appears the devices are slower to update.
-
- Hyperion addon & PS3 Camera: Same errors, also less frequent. Bluetooth tracking continues to work.
-
- MotionEye & PS3 Eye: Same errors. But far less frequent than either of the above scenarios. Bluetooth tracking continues to work.
I might leave the last scenario running overnight to see if the bluetooth eventually fails.
Very confused with this, there’s obviously some conflict between the usb and bluetooth. Can’t narrow down the causes but it would seem that there is some difference in the way MotionEye & Hyperion are handling the usb traffic which would account for some of the results above.
I’ve started another thread on it and will stop spamming you here 
Where do the preferences live? I want to do a clean install after playing around with the settings and after uninstalling the add on, checking in Portainer to confirm it’s definitely gone, on reinstalling everything comes back exactly as it was before.
They are in your config folder (where the configuration.yaml is) but located in the subdirectory called “hyperion”, you can remove that entire directory to erase the configuration.
1 Like
Thanks, that did it. Don’t think of looking there as it was in it’s own container.
Something not right with USB grabbing on mine unfortunately.
On a Pi running Hyperbian I just plug the grabber in and it starts working with no more than flicking the USB Capture button in the Remote Control panel.
In the add on, HA running in a VM with Windows host, the logs show it’s picked the grabber up fine and recognised it correctly…
2020-11-06T01:42:45.386Z [hyperiond V4L2:AUTO] (INFO) search for usable video devices
2020-11-06T01:42:45.387Z [hyperiond V4L2:AUTO] (INFO) test v4l device: /dev/video0
2020-11-06T01:42:45.398Z [hyperiond V4L2:AUTO] (DEBUG) (V4L2Grabber.cpp:696:init_device()) Set resolution to width=1920 height=1080
2020-11-06T01:42:45.412Z [hyperiond V4L2:AUTO] (DEBUG) (V4L2Grabber.cpp:713:init_device()) Set framerate to 5 fps
2020-11-06T01:42:45.413Z [hyperiond V4L2:AUTO] (DEBUG) (V4L2Grabber.cpp:735:init_device()) Pixel format=YUYV
2020-11-06T01:42:45.429Z [hyperiond V4L2:AUTO] (INFO) found usable v4l2 device: /dev/video0 (UVC Camera (534d:2109): USB Vid)
2020-11-06T01:42:45.446Z [hyperiond V4L2:AUTO] (INFO) Started
…but it doesn’t appear as a source…
Any ideas what the problem might be?
I was having the same issue as above so I uninstalled it, and re-installed it again and now can’t even get in the web-page. It just crashes right after pressing start.
In the log I get the following error:
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
/hyperion/hyperiond: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
[cmd] /run.sh exited 127
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
Any idea how to fix it?
Yes, I’ve tried deleting it, changing permissions on it, whitelisting it, changing ports on the configuration. Nothing seems to change the error.
Whenever I delete it and start again it just creates the folder. Is anything else supposed to be in there?
In that folder there should be an empty ‘custom-effects’ folder and a ‘db’ folder with ‘hyperion.db’ inside.
Continuing with my grabber problem, I swapped it back to a Pi with Hyperbian again where it just works with no input from myself and checking the logs showed the exact same as before bar these extra lines after what I posted earlier…
2020-11-08T15:01:30.929Z [hyperiond V4L2:auto] (DEBUG) (GrabberWrapper.cpp:48:start()) Grabber start()
2020-11-08T15:01:31.082Z [hyperiond HYPERION] (DEBUG) (PriorityMuxer.cpp:238:setInputImage()) Priority 240 is now active
2020-11-08T15:01:31.083Z [hyperiond HYPERION] (DEBUG) (PriorityMuxer.cpp:333:setCurrentTime()) Set visible priority to 240
2020-11-08T15:01:31.083Z [hyperiond HYPERION] (DEBUG) (Hyperion.cpp:538:handlPriorityChangedLedDevice()) priority[240], previousPriority[250]
No errors appear in any logs in the add on when turning USB Capture on.
@bradsjm I’ve been trying to persuade my grabber to kick in as a source but still no luck.Whilst trying other settings to see if any affect it a lot of choices, eg the Platform capture type flag errors in the log saying they ''can not be instantiated, because it has been left out from the build".
Do I assume this means you only partially built it and it may be missing something fundamental that’s stopping it work for me?
Good question, however the add-on doesn’t build the application, it simply uses an Ubuntu base image and then simply downloads and installs the release .DEB file compiled and provided by Hyperion at https://github.com/hyperion-project/hyperion.ng/releases/tag/2.0.0-alpha.8 and then runs the binary. There is nothing for me to change or adjust.
I’m not aware that Hyperion test or support Docker installs of the software so the issues found may simply be that some things do not work properly when used in Docker.
Thanks @bradsjm for the explanation, I checked the issues on that GitHub link and found it has been reported by a couple of others though nothing has been done about it as yet. One was on raspbian and one on LibreELEC so looks like nothing to do with being on Docker. Have added my experience and will update with any news.
This add on is the perfect solution to my scenario if they can fix it so thanks again for creating it.
Can I ask what you use Hyperion Android Grabber on?
I’m running the Android Grabber on my Nvidia Shield 2017 and 2019 Pro. I found it was not reliable on the 2019 tube version (32-bit and less RAM may be why). I use it with Kodi and/or Plex along with Tivimate for TV. It won’t work with DRM so Amazon Video, Netflix etc. but I rarely use those apps anyway.
Thanks, most of my general media consumption is through a Fire TV stick but is DRM protected stuff like Amazon and Netflix unfortunately. I do however have Kodi on the stick as well as my HTPC as the Netflix add on is ironically the only way to get Atmos output so may give that grabber a go to see if DRM still blights it through that.
Is there something simple i could change to make it install alpha 6 to see if that works any better with the grabber?
Had anyone had any issues with opening ports? 8090 seems to be working fine but 19445 or 19400 are not accessible. Is there a way to debug it somehow? I’m on RPi 4 using HassOS 5.3