first of all, great job!! I’m very glad with my Vero 4k+, apart from my issue
I’m doing a lot of tv show recordings and also I’m watching a lot of TV shows. With the Vero 4K+ I recognized some flickering parts in the pictures during playback. Means, that the playback works as expected, but some parts or areas of the pictures suddenly flickers/stutters. It’s often in recordings, and also sometimes in Live TV (TVheadend).
In recordings, if the issue occurs, It’s always at the same time and picture area. So, it’s a good reprdouction environment
Furthermore, the playback needs to be started at the beginning, for getting the issue. If I do one ore more steps forwards or backwards, the issue doesn’t occure anymore.
By pressing “DOWN” for starting at the beginning, the issue is back, until I do some steps for/backwards.
I can reproduce this issue only on my Vero 4K+ (OSMC/Estuary skin). On my NUC6CAY with Windows/Kodi or the same OSMC Version (2018-12.01) on a Pi II, this issue doesn’t occur at all. All boxes were directly connected to TV or monitor, no AVR. The issue occurs on both, TV and monitors.
I also reinstall many times to isolate the issue. Just reinstall, answer the initial questions, connect the USB stick (for excluding LAN issues), start the video and the issue occurs. It occurs in OSMC and Estuary skin.
@sam_nazarko
Hey Sam, your message reached me by sky42. Thank you in advanced for your support. I didn’t want to bump this thread or stress you because I know your efforts for releasing v18.
I uploaded an example file to the corresponding space. Although the issues appearing during the whole minute in this file, the best scene to see the issue is at the 23rd second. If you start the file directly from the beginning without any jump for- or backward, the head of Jason Priestly is flickering in this scene.
JFYI, it doesn’t make any difference where this or other files are played from (USB Stick, SD Card, network share), this kind of issues are always the same.
Furthermore, sky42 and me were able to do cross testings today. So, here are some more information.
Testing with the Vero4K+ of sky42 in the OSMC skin => exact the same issue at the same time and screen area
Testing with the Vero4K+ of sky42, OpenELEC 9.0.1 sky42 version => exact the same issue at the same time and screen area
So, I’m very happing because now I can assume that you could the issue as well.
Some more tests:
Testing with a K1 PRo (MeeCool ) native Android 7.1.2, => no issue at all, playing with the default MX Player
Testing with a K1 PRo (MeeCool ) OpenELEC 9.0.1 Sky42 version => flickering at other time stamps and screen areas
Jumping for- or backward is mitigated the issue at all occurrences.
If you need any further information just let me know.
Thanks for your patience. This should now be resolved. Under the current scheme, we would reset the decoder in the event of no IDR to try and eliminate the discontinuity. But this is not necessary here. I’ve adjusted the error recovery to exempt this as a condition to reset the decoder.
I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:
Add the following line: deb http://apt.osmc.tv stretch-devel main
Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
Your system should have have received the update.
Please see if the issue is resolved.
I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.
I was quick checking the patch and the test sample now starts around 4 or 5 seconds and not at the beginning. I think the problem is gone, but with my bad eyes i am not sure.
Edit: I forgot to mention there was a Kodi nightly update too from 430 or 431 to 432.
@JimKnopf uh nice this seeting i did search/wish for a long time and hope i can nail pvr at 50 Hz with that
HEUREKA!
Yes, the flickers are gone. And, as @sky42 already mentioned, the visual part of the video file is starting some seconds later. If this is because of “a whole frame thing”, I’ll need to do some research for cutting the records in the right way. But this shouldn’t bother you.
Thanks for this hint. I’ll double check my files with VideoRedo in the future.
Normally, I do my cuttings with TSDoctor and I’m putting value to ensure that start and end is an “I-Frame”.