search

pesintta / vdr-plugin-vaapidevice

VDR VAAPIDevice Plug-in
9 stars 12 forks source link

FastForward / Rewind not working #71

Open Space2Man opened 6 years ago

Space2Man commented 6 years ago

Hi Antti, Hi Rolf,

thanks for all your hard work on vaapidevice. I just noticed one issue. If I FastForward or Rewind then the "position" clock is not updating and if you press play again you are at the same time where you started FastForward / Rewind ... even if you let FF/Rew run for quite some time ...

Not sure where this started ... my last "known good" commit (6372704835b62bee882feed92686edc75e70b55f) is also affected ...

Thanks and best regards,

Jochen

jupe76 commented 6 years ago

No such issues here (ffmpeg 3.4.2, libva-2.1.0-1, X.Org 1.19.6, vdr 2.3.8)

pesintta commented 6 years ago

Tested various samples and also could not reproduce the issue. (ffmpeg 3.3.6, libva-2.1.0-1, X.Org 1.19.5, vdr 2.3.8). Is there anything special in the recordings that you use, e.g pes instead of ts, h.264 or mpeg-2 etc.?

Also, does your vdr have write-access to recordings so that it is able to create/update the resume files? Read-only access might cause the described behavior.

Space2Man commented 6 years ago

Hm, yes, looks like only some recordings (most from the same channel -- SuperRTL) are affected. I also saw that I have included the naludump patch although it's deactivated in settings. ... I will compile without that patch ... if required I can also provide a sample of the recordings ...

That also explains why it was not noticed before ... our kids do not ff/rew and I only noticed when trying to cut some series for them ...

Space2Man commented 6 years ago

FYI: I have removed the naludump patch from the build process and did a small test which looked fine. But I will know more once the recording of Toggo channel has finished tomorrow afternoon.

Space2Man commented 6 years ago

Hi,

it's a very strange behaviour ... while "Spirit" was working almost fine "Dragons" was a complete mess again. Even if cut it has the same issue.

But I did one test on my nvidia based system with softhddevice ... same issue with the same recording. So either something "old" in softhddevice/vaapidevice is broken or something common (like ffmpeg) or the TV station broadcasts some kind of crap ...

Any hint how I can verify / exclude that? I can provide a short sample (100MB).

Thanks and best regards,

Jochen
pesintta commented 6 years ago

I think the problem might be in the demuxer part of original softhddevice. We haven't really modified that code so same bug might be present in all versions of the plugin.

A sample of few minutes could be of interest. I guess you could contact us privately so @rofafor can then take a look.

Space2Man commented 6 years ago

@rofafor did you get my message via vdr-portal?

rofafor commented 6 years ago

I did, but the provided URL doesn't work.

Space2Man commented 6 years ago

Ah, sorry, my fault ... geo-blocking was still active ... please try again :)

rofafor commented 6 years ago

Got it, thanks!

rofafor commented 6 years ago

The bug was introduced in commit https://github.com/pesintta/vdr-plugin-vaapidevice/commit/df3464bbac77ebf28e9fa7d47dd99965fe9e5ddc

Space2Man commented 6 years ago

Hi, can I somehow assist in troubleshooting / testing?

rofafor commented 6 years ago

Sorry, I haven't had any time to investigate the actual bug - just bisecting the offending commit after I got the sample.

rofafor commented 5 years ago

This has been fixed in https://github.com/pesintta/vdr-plugin-vaapidevice/pull/122, but unfortunately it still contains a few other showstoppers.