Samsung UN65F6300 SmartTV & NextPVR Freeze Problem

[meccano]

I upgraded from GB-PVR/MediaMVP to NextPVR
with a Samsung SmartTV last year but I'm having
a newer freeze issue that is very annoying.

When I first upgraded, a very significant number
of recorded SD TV shows with marked commercials
looped uncontrollably during initial playback.
The first few seconds were shown over and over.
I initially avoided this issue using "999"
but eventually post-processed the .edl file
to remove short initial commercial skips;
this fixed most loops.

I'm not sure when it started but my most recent
issue is a playback freeze near the end of many shows.
For example, tonight we watched Top Chef.
For 90% of the show, everything went well.
Then near the finale, the playback freezes at 20:10.
No keypresses restart the video so I cancel the
current playback, restart the show and try to
skip forward to where it froze. Often, but not always,
my skip forward requests are ignored but eventually
I manage to restart the video at the frozen position.

This gets very tedious when you have to do it over and over!

My current TV show, logs and configuration info is here:

http://meccano.dlinkddns.com/pvr/SmartTV...ck_Freeze/

Is there any way to prevent this problem?
Is it a Samsung Smart TV issue or a NextPVR issue?
How can I tell?

[fred250]

Hi Meccano,

The Samsung F-series sadly isn’t one of the better media players around.
It does not handle seeking in mpeg-ts very well.
You need to set “seek hinting On” in app settings (000) in order to get any descent skip operation at all out of the F-series.

My guess is that the file itself or timestamps of your newly recorded files are more corrupt than they used to be. Bad files and timestamps are the F-series worst enemy.

What if you play an old recording from the same SD channel? Does it play well or just as bad?
What if you transcode or remux the file, does it help?
From memory I’d say the F-series seeks ok in .mp4 and .mkv files.

Both stronger and weaker antenna-signal may cause the recordings to become almost unseekable with certain devices while playing perfectly well on others.

I will try to download your example ts-file and have a look at it later on this week.

/Fred

[meccano]

Fred,

Yes, I have seek hinting ON in app settings.
(By the way, it would be nice if the 000 command were mentioned on client3.html
as a memory aide.)

I have done some more experimentation. Last night's TV did not exhibit the freezing problem
which is the most aggravating issue but seeking issues did come up in another show
(Man Fire Food_20170112_19302000.ts).

I have been recording from an older Digital Box (General Instrument SD) for many years.
One in a blue moon a recorded show (mpg) had major timeline issues, but this was not a
regular occurrence.

In the past I have tested converting the .ts to .mpg but this never seemed to help.

ffmpeg.exe -y -i %infile.ts% -vcodec copy -acodec copy %outfile.mpg%

Based upon your comments I tested .mkv as well:

ffmpeg.exe -y -i %infile.ts% -vcodec copy -acodec copy %outfile.mkv%

To my surprise, seeking within the .mkv works very well, even though I did
not re-encode any of the audio or video. Since this copy process does not use
much CPU I'll have to test further and maybe start converting all recorded
shows to mkv.

Thank you very much for this suggestion.

One last thing I meant to mention earlier - when I upgraded to NextPVR 3.9.2
I noticed that the onscreen show name now includes encoded characters,
e.g. \ displays as %5C. The problem is that the show title runs off the right
hand side of the screen so it would be nice if this could be re-shortened.
Is this a NextPVR fix or something within your client?

David

[fred250]

Hi David,

Just had quick look at your Top Chef recording and I can only confirm that it won't seek very well on my Samsung F-series blu-ray either while it plays and seeks well on all other clients I tested.
It doubt is has anything to do with your upgrade of NextPVR.

To my surprise, seeking within the .mkv works very well, even though I did
not re-encode any of the audio or video.

The .mkv container has its own timestamp/index table making seeking much more reliable than if depending on crappy timestamps in the file.

One last thing I meant to mention earlier - when I upgraded to NextPVR 3.9.2
I noticed that the onscreen show name now includes encoded characters,
e.g. \ displays as %5C. The problem is that the show title runs off the right
hand side of the screen so it would be nice if this could be re-shortened.
Is this a NextPVR fix or something within your client?

Thanks for pointing it out. I hadn’t noticed sub's change to how file names are encoded.

I will provide a fix in a few days time.

/Fred

[meccano]

Since switching to MKVs I haven't had any further freeze issues and seeking
works much, much better.

I needed to retain my EDL post-processing as the presence of short initial commercial skips caused show RESUME to often not work.

I wasn't aware of the MKV timestamp/index feature - this explains why they work better.

Thank you very much for your assistance!

[fred250]

I needed to retain my EDL post-processing as the presence of short initial commercial skips caused show RESUME to often not work.

You may try setting seek hinting OFF with your .mkv files. It shouldn’t be needed and may fix your resume problem.

/Fred

[fred250]

One last thing I meant to mention earlier - when I upgraded to NextPVR 3.9.2
I noticed that the onscreen show name now includes encoded characters,
e.g. \ displays as %5C. The problem is that the show title runs off the right
hand side of the screen so it would be nice if this could be re-shortened.
Is this a NextPVR fix or something within your client?

Fixed in 0.29.2, available in the Smart TV apploader.

How to update? Look here http://forums.nextpvr.com/showthread.php...ung-and-LG

/Fred

[meccano]

Fred,

I installed 0.29.2 and the long video title issue has been fixed. Thanks.

I also tested using Seek Hinting OFF but this did not prevent issues with RESUME.

Thanks again for your assistance.

David