Posts by Hauke

  • [WORKAROUND] DVB-T2: Increase in data errors after platform switch

    Just installed the most recent Raspberry Pi OS on my RaspPi 4 and put tvheadend on it. Interesting: The same I²C errors are there, and I've glitches...

    So, I have a RPi 3 with buster, but still on kernel 4.19, and a RPi 4 with buster, but kernel 5.10. Pi 3: Works nice and stable. Pi 4: I²C errors, glitches.

    Anyone has an idea what might be the change that happened that may cause the problem?


    EDIT: Just put the SD card from the RPi4 into my RPI 3, so exact same OS/software/everything --> No I²C errors/Glitches. It obviously has something to do with the RPi 4 hardware/drivers...


    EDITEDIT: seems to be kind of a known problem: Haupauge DualHD (em28xx) driver broken. Kernel spam "write to i2c device at 0xcX failed with unknown error" on RPi4 - Raspberry Pi Forums and there seems to be a workaround. Will try this soon and report


    EDITEDITEDIT: The workaround indeed works. I²C errors remain, but TV reception is stable and I have nearly no errors in picture or audio. It's still a bit below par with RPi 3, but fully acceptable.

  • [WORKAROUND] DVB-T2: Increase in data errors after platform switch

    I just tried the nightly build, but TVheadend is unwilling to start. After installing the Addon, I cannot navigate to the tvheadend standard webpage. Also, using ps, I cant find a process for tvheadend. And, switching on debug/trace logging, there's no log created for tvheadend, which I suppose means that it never starts.

    So, unfortunately I cannot check if the receiver works OK. I see no i²C errors, but I suppose they'll onyl show up when the receiver is used in earnest...

    What am I missing? Anyone was able to start tvheadend with the nightly build?

    Tried the oldest and newest nightly I could find for RPi4.

  • [WORKAROUND] DVB-T2: Increase in data errors after platform switch

    Hi folks,

    I'm a bit at a loss how to tackle the following problem: I use WinTV dualHD DVB-T2 receiver now since quite a while. In the past I used LePotato Amlogic device, but since the kernel did not properly support the DVB-T2 stick, I had a Raspberry Pi 3 running with a then up-to-date 4.19 kernel/Raspbian Buster and tvheadend on it, and subscribed to that from LePotato. That worked stable and very well. Only thing that annoyed me was that I needed to waste power on two devices, and when Raspberry Pi 4 came out, I switched to it and attached the DVB-T2 stick to it, with immediate success.

    But ever since I have the problem that I have a lot more data errors, which result in image and/or audio glitches. I suspected power issues and now put a powered USB hub inbetween, and it currently seems as if it is better, but I still have not nearly the same stability as I had with the Raspberry Pi 3.

    I've also tried all three DVB driver packeges, there's basically no difference.

    I've exchanged cables, no difference.

    I even have two of the receivers and changed them, no difference.

    In dmsg I find repeated entries like this:

    Code
    [   30.296916] em28xx 1-1.4:1.0: write to i2c device at 0xc8 failed with unknown error (status=128)

    I'm atually considering putting the Raspberry Pi 3 back into my network... For testing I just did, and the ic2-errors do not show up the the Pi 3's dmesg...


    Any help appreciated!

  • 9.2.1 on RPi4: HEVC from TV recording has no playback controls

    Quote from Nicolas

    would be interesting what Happens, If you mount the Share as lokal Volume....

    Works! Playback controls there if I mount the CIFS volume locally... Does this tell anything helpful?


    Btw.: For me it will be of no importance. The disk is a network place currently since it is mounted to the AMlogic based media center which I plan to replace with Raspberry 4 - so the drive will be a local drive after all.

  • 9.2.1 on RPi4: HEVC from TV recording has no playback controls

    I've tried to narrow things a bit down. With the example file provided earlier, I reduced file size in 50 MB chunks until the playback controls turned up, which was when I reached file size 2085391219 bytes. Then I verified by creating a file 50 MB larger, i.e. 2135391220 bytes. No playback controls there. So I now on this file that just don't works I did

    Code
      tail -c 50000000 broken.ts > offending_part.ts

    and just only played this part. And, lo and behold, I have playback controls, so I'd infer it's not in the data.


    I clamied earlier that the problem was not related to file size, since I had 1.4 GB recordings showing the problems - strange enough, I can no longer reproduce it, although I swear they showed the problem! Perhaps at some point the player just gets broken and a reboot is required.


    So I picked another, different file not working, and tried shorten it - this time by 10 MB chunks -, with similar but not exactly the same results: 2154473940 bytes have plackback control (larger than above's not-working-file), 2169473940 bytes no longer have playback controls.


    Now it comes: After this, the file in the beginning of the post I said is not working, having 2135391220 bytes, is now working - so it is not even a strictly reproducible problem (which might explain why earlier I claimed a 1.4 GB did not work). RAM seems not to be the problem, I used a small python script to eat up loads of RAM, playback control situation stayed the same. Stupid me, ran the script on the wrong machine... will redo... Redid: RAM is not affecting it.


    After a reboot, situation remaind as described: only the largest of the truncated files does not show playback controls...


    Maybe it is a problem of Raspberry OS still being 32 bit? The above file sizes not working are remarkably close to 1024 * 1024 * 1024 bytes = 2.147.483.648 bytes, and as far as I understand, this is a limit for 32 bit systems. Still, somehow I don't believe that's the reason - many media files are larger... And the second, working is already beyond that limit...


    Last thing possible: The Raspberry works through all files in an asynchronous process and stores metadata in its database. And when the files are fresh, the duration is missing. After a while, the process is done and the information is there and suddenly the files work... Still, I don't believe it: Many files not working are there longer than those not working in the beginneng but working now. Still, what I will do is leave the device running for a few hours and see if things have changed...


    In the meanwhile: Does what I write above help anyone to get this puzzle solved?


    EDIT!!!: Tried something I should have done in the first place: Copied the file from the network location to RPi SD card --> Playback controls are there for the original file! I guess that should help finding th issue...?

    Edit 2: Also USB stick works locally, but not via network.

  • 9.2.1 on RPi4: HEVC from TV recording has no playback controls

    OK, trying to make sense of the kodi.log. As far as I can tell that's the portion of the log between start and stop of the movie, and loading it into the media library (first/last line - cannot paste the whole log portion. Full log is here) :

    Code
    2020-08-27 12:37:14.693 T:3002069872   DEBUG: CLibInputTouch::ProcessTouchUp - touch input up
[...]
2020-08-27 12:37:40.819 T:3011884368   DEBUG: ------ Window Init (Home.xml) ------

    In there the following lines strike me as odd:


    Code
    2020-08-27 12:37:24.760 T:2639012720    INFO: ffmpeg[9D4C2370]:   Duration: N/A, start: 67418.302400, bitrate: N/A

    It seems the decode cannot evaluate how long the playing time is --> Would explain why I cannot move in the file. Some lines above I find

    Code
    2020-08-27 12:37:24.422 T:2639012720   DEBUG: Open - avformat_find_stream_info starting

    and then a lot of errors. It seems to have trouble finding something named PPS and NAL.


    Later, when playing, it uses MMAL, so not ffmpeg, But ffmpeg tries - all the time:

    Code
    ffmpeg[ABD12370]: [hevc] av_rpi_zc_ref: *** Not one of our buffers: NULL

    It seems that ffmpeg does not have permissions to access MMAL stream/buffers? But if this would be the problem: Why would it work for other streams?


    I don't know, I have difficulties understanding the log - hopefully someone with more insights can make sense of it...

  • 9.2.1 on RPi4: HEVC from TV recording has no playback controls

    Quote from Nicolas

    Hauke


    Could it be that the Stream has continue Errors?

    Oh, I'm sure it has: The very same video caused problems on one of the earlier versions of LibreELEC bacause of a severe continuity error somewhere in the middle. But if I truncate the video as described earlier, that exact continuity error is in the truncated part, but playback controls are there. I suppose the suggestion that fill bits or something like that cause the issue is more likely. What I'll try is to truncate the file from the back, i.e. cutting away bytes until it works, and then see what actually is in these bytes. Will keep you posted.

  • 9.2.1 on RPi4: HEVC from TV recording has no playback controls

    Quote from Mario77

    On my Rpi 2 it's working fine with skin aeon nox silvo but I only see 2 controls with estuary skin..that s the one you r using..from your screenshot..Libreelec on Rpi...h265 videos where unplayable 2 years ago but now they done a huge inroad and plays flawlessly..

    You say that Rpi2 can do H.265 in software decoding? *wow*...

    Quote from Mario77

    Play,pause,rewind,ff they all work on mine...try to post the unwatchable sample and i ll try again..

    I a few minutes ago edited my earlier post containing the links, file is back there. Or here :-)