Posts by Hauke

Hi folks,

I've after quite a while updated my RPi 4 from Libreelec 9 to 10.0.4 - did a clean install and set things up like before step by step manually. Now, when I play Live-TV via DVB-T2 (Germany), the sound ever so slightly gets out of lip sync, then there's a very short pause (just a "click") and sound is back in lip sync. This happens every few seconds. The TV stream is HEVC with AAC. Audio goes through Raspberry default 3.5 mm Jack (BCM sound). Tried playing around with refresh rates etc., nothing seems to have any effect. When I record the signal and play it back from harddisk, audio is flawless! So I infer that the data stream from the receiver is OK.

I use TVHeadend 4.2 addon, and the corresponding PVR addon.

Tried to use Libreelec 11 beta, same effect (did an inplace upgrade).

Any ideas?

A bit more details:

After updating I was actually quite pleased that my DVB-T2 receiver (Hauppauge WinTV dualHD) is now natively supported by the kernel and works flawless - if I connect to TVheadend on the RPi from my PC, I can tune in to two MUXes and play back several TV streams from these MUXes, not issues with Audio. From this I infer it is a playback issue on the Raspberry. With Libreelec 9 the kernel was too old for the receiver, which caused severe picture distortions, which is why I had the receiver connected to a second Raspberry 3 with Raspberry OS and tvheadend running on it, and connecting the PVR on Libreelec to that server. So the situation has changed in that regard.

Thanks!

Hauke

An update after a few weeks of using the setup: It is better, but still not good. The number of data errors is down quite a bit, but still once in a while they come at the worst imaginable moment. So I'll fire up the Pi 3 again and wait for further Pi 4 firmware improvements... *Sigh*

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.

With the addon from the nightly I get tvheadend up'n'running. Unfortunately the I²C errors persist, and also the glitches Any other ideas?

Update: Just tried the 10.0 nightly, still same errors.

OK, thanks. I used exactly that one... Will try again. And as you reccomended try another addon version if I still do not succeed.

Quote from ghtester

Of course, it works fine. Try a fresh install from scratch then.

Strange - I did a fresh install... Which version are you using specifically?

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.

Hi elliottmc, you're right, and thus I'd have understood if RPi 3 would be working more unstable than RPi 4, but it's exactly other way round...

Thanks, will give it a try! And will give feedback

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:

[   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!

Quote from Nicolas

Turns Out it Was an issue with the rights of the folder.

Will double check, but basically the folder is open for everyone anonymously for read and write. And mounting the share locally will not change the access rights I suppose...

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.

Quote from Mario77

I see you have teletext in your recordings?Can you try to disable that from tvheadend side..create a blacklist from stream profile you are using to record?

Sorry for not answering this - I think no need to try this - see my last post - especially the Edits...

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

  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.

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) :

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:

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

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:

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...

Quote from Mario77

Is this issue with 1 recording or with all? [...]

You have many ffmpeg errors on your logs..

It's all recordings.

Which log would I look at? Would teh kodi.log debug log be right? Is ffmpeg involved if I do hardware decoding on RPi 4?

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.

Quote from Mario77

probably something to do with Rpi4..

I guess you're right... anyone here feeling like he/she can pick up the issue?