Posts by jahutchi

    No idea how you'd install uhubctl on Libreelec I'm afraid. I have my tvheadend (server) setup on Arch Linux.

    I believe the patch could help but the request should perhaps go to Linux developers instead.

    That is certainly my intention, though I'm firstly trying to prove one way or the other whether the patch has a positive effect.

    My problem is that it takes several weeks for the issue to surface on my setup. I therefore posted the patch here, hoping for some feedback from someone who is encountering the issue more readily.

    Failing that, I'll probably leave it running with the patch for a few weeks/months on my own setup; to try and seek proof either way as to whether the patch has a positive effect.

    I have also suffered for a number of years on different Intel-based x86_64 machines, whereby intermittent -110 (timeout) messages are encountered for adapters running in the dvbsky.c module (for me, the MyGica T230 DVB-T2 adapters and DVBSky S960 DVB-S2 adapters). Sometimes the machine can go for several weeks (or months) and be OK, then it will randomly encounter the error and require a reboot to fix it.

    Personally, I worked around the issue by buying a usb hub and programmatically cycling the usb port power using uhubctl when the error is encountered (thus not requiring a full reboot), but this is obviously far from ideal.

    I have recently made some headway in debugging the underlying cause in the driver. From what I've found it seems to occur more frequently when the TVheadend status period is set lower. e.g. with the status read period set to 8000ms (maximum) the issue occurs far less frequently for me.

    I think it might be caused by a race condition when a thread attempts to update the last_lock status of the device, whilst another reads the state buffers (which are defined in the same struct as last_lock) to send i2c messages. I have attached a patch that I am trialling on my own machine, but since it can take several weeks for this to surface on my hardware I thought I would share this patch incase anyone else is able/willing to test on hardware where the error is more frequent. Note: this is only intended to fix those random -110 timeout problems with adapters running inside the dvbsky module (e.g. MyGica) - no ideas what the (similar) issue is with the Astrometa adapter as reported earlier in this thread - I don't own one of those adapters.

    I gave this a go on my Arch linux NUC 8i3BEH using the build kindly supplied by chcore.

    Played some 4k HDR content with DRM Prime & HDR enabled in kodi settings.

    Seemed to work nicely and the content was correctly recognised by my TV as HDR.

    However, whenever I play such files I find the following dump in my kernel log:

    This doesn't seem to effect playback as far as I can tell.

    This was on the latest stable kernel v5.19.9 with all arch linux packages upto date, and libva-intel-driver installed for VAAPI.

    Did some testing, and it seems to work pretty well (thanks again smp). Did notice a couple of issues though:

    1. Deinterlacing does not work/cannot be enabled when DRM PRIME is enabled. This means I will need to manually turn on DRM PRIME whenever I intend to watch HDR content, then turn it back off. Not ideal, how far off is deinterlacing support? Maybe a good idea to have an option or advancedsetting that uses DRM PRIME only for HDR content until it is implemented.

    2. Is it just me, or is text noticeably more aliased when HDR is active? Both subtitles and OSD are affected

    chcore I also run archlinux on my intel nuc 8i3beh and was about to try compiling a hdr nexus build like you did. Before I go to all that bother, would you consider posting your pre-compiled binaries (zst files) somewhere?

    What do I have to do to apply it to my RPI myself?

    A few choices:

    1) Compile & install your own kernel from the raspbian sources, with my patch applied: Kernel building - Raspberry Pi Documentation

    2) My patch found it's way into media_tree just a couple of days ago: media_tree.git - Upstream media tree for Remote Controllers, V4L and DVB so you could to build and install the drivers yourself from media_tree to run within your existing kernel: https://www.linuxtv.org/wiki/index.php/how_to_obtain,_build_and_install_v4l-dvb_device_drivers

    3) (If both above options are too scary), then wait until the patch filters it's way down to mainstream raspbian kernel.

    smp In light of the kernel mutex handoff changes I do wonder whether it'd be wise to adjust the i2c mutex lock in dvbsky.c to be non-interruptible. I can see this is the way it's done in several other of the dvb-usb-v2 drivers (though not all)

    I have no idea whether this will make things better or worse, but just thought it may be worth a shot if you have time to test it (find attached).

    This builds on my previous patch to use a single mutex for all r/w ops, but also adjusts the i2c mutex lock to be non-interruptible.

    Note: I had to give the attachment a .txt extension in order for it to upload.

    Other than this I'm all out of ideas.

    I didn't check dmesg. It failed like it always did with newer kernels - it works for a while but a brief signal disruption randomly triggers the failure. I'm now back to kernel 4.8.16 for everyday use.

    Fair enough - I suspect we would have seen a bunch of timeout (-110) errors as previously, but without much indication of exactly why the device has started to timeout.

    Just spent a fair amount of time ploughing through the debug traces on bugzilla, and cross-checking some commits that happened during the 4.10 kernel developments.

    This one looks suspect since the attach logic in dvbsky.c appears to attempt to modify fe->ops

    Does the attached patch to revert this change for the m88ds3103 driver have any effect ?

    Unfortunately, I do not currently have an environment upon which to beta test this myself.