Recorded TV sometimes has playback errors (1 Viewer)

[deamon_knight]

I've be running MediaPortal to record live TV (ATSC Broadcast) for about a month now. Most of the time this works really well. But I'm encountering some recordings that skip forward about a minute during regular playback, or, when stepping around the recording, will 'repeat'. Example: I've have an Hour recording and around the 22 min mark the playback cuts to a different scene scene and the timestamp is around the 23 minute mark. Also, trying to step forward 30 sec sometimes skips right past this, but other times skips back to around the 21 minute mark. Pulling the file to another computer for playback, I had it go from the 22 min to the 21 min to the 23 min mark without any input on my end. It seems like the time index is messed up and can sometimes end up point to an earlier frame rather than the next frame. This happens on different channels and shows at different times. I usually don't watch live TV so my local broadcasters could be dropping about a minute of TV from time to time, or some interference could be the cause, but I'd expect to see snow or pixel-garbage for the time rather than skipping. Any idea whats going on?

Thanks

 

[Owlsroost]

If you attach the logs (after playing one of the 'problem' files) I'll take a look.

 

[deamon_knight]

Thanks Owlsroost, whats the best way to do this. I know how to post logs, but do I need to watch the whole file up to the point of error, or just a few minutes? Or something else?

 

[Owlsroost]

Maybe start 5 minutes before to 5 minutes after the 'problem' area ?

 

[deamon_knight]

Logs attached, problem begins at about 50:45 for this particular recording.

 

[Owlsroost]

In the TsReader.log, there is a section of the stream missing (generating a jump in the timestamps) - over 3.5 minutes in fact:

[2015-04-27 14:43:17,258] [ e331b98] [25dc] - DeMultiplexer::FillVideoMPEG2 pts jump found : 218.518295 3270.329102, 3051.810791

The first number is the 'jump' length (218.518295 sec), the second number is the new timestamp, followed by the previous timestamp.

If it was a short jump (less than two seconds), you would probably see corruptions and freezing on-screen, but as it's a long jump TsReader re-synchronises to the stream to minimise the disruption.

The reason why there is a gap in the recording is in the TV server TsWriter log :

[2015-04-27 01:43:52,497] [ab77330] [c70] - Recorder:unable to write file:'F:\Recorded TV\06.1 ABC\Burn Notice\Burn Notice - 2015-04-27 - Forget Me Not.ts' 112 255868 dcc
[2015-04-27 01:43:52,646] [ab77330] [c70] - Recorder:unable to write file:'F:\Recorded TV\06.1 ABC\Burn Notice\Burn Notice - 2015-04-27 - Forget Me Not.ts' 112 255868 dcc
[2015-04-27 01:43:52,770] [ab77330] [c70] - Recorder:unable to write file:'F:\Recorded TV\06.1 ABC\Burn Notice\Burn Notice - 2015-04-27 - Forget Me Not.ts' 112 255868 dcc
[2015-04-27 01:43:52,919] [ab77330] [c70] - Recorder:unable to write file:'F:\Recorded TV\06.1 ABC\Burn Notice\Burn Notice - 2015-04-27 - Forget Me Not.ts' 112 255868 dcc
......
to
......
[2015-04-27 01:47:31,399] [ab77330] [19fc] - Recorder:unable to write file:'F:\Recorded TV\10.1 CBS\Blue Bloods\Blue Bloods - 2015-04-27 - E322 - The Bitter End.ts' 112 255868 19c0
[2015-04-27 01:47:31,412] [ab77330] [c70] - Recorder:unable to write file:'F:\Recorded TV\06.1 ABC\Burn Notice\Burn Notice - 2015-04-27 - Forget Me Not.ts' 112 255868 dcc
[2015-04-27 01:47:31,536] [ab77330] [c70] - Recorder:unable to write file:'F:\Recorded TV\06.2 MYTV\The Outer Limits\The Outer Limits - 2015-04-27 - E1026 - The Guests.ts' 112 255868 e68
[2015-04-27 01:47:31,538] [ab77330] [19fc] - Recorder:unable to write file:'F:\Recorded TV\10.2 Antenna\Mr. Belvedere\Mr. Belvedere - 2015-04-27 - Fall Guy.ts' 112 255868 1594

(There are 'Recorder:unable to write file' entries for some other recordings in the log as well).

Is drive F: a local drive or is it on a remote fileserver ?
Is it getting full ?
Is there something else running which could be generating a lot of disk activity ?

 

[mm1352000]

In case it wasn't clear, the error code is the second part of those TsWriter log entries.

[2015-04-27 01:47:31,399] [ab77330] [19fc] - Recorder:unable to write file:'F:\Recorded TV\10.1 CBS\Blue Bloods\Blue Bloods - 2015-04-27 - E322 - The Bitter End.ts' 112 255868 19c0

112 is 0x70 in hex.
Look up the code here:
https://msdn.microsoft.com/en-us/library/cc231199.aspx

...and we find it means ERROR_DISK_FULL.

 

[deamon_knight]

Interesting. I have a new 2 TB Western Digital Green Drive. That drive is Divided into a 500GB Partition and a 1.5 TB Partition. The F: Drive is the 500GB Partition, which I am using only as the location for recorded TV, the other partition is used for general media storage (TV & Movie DVDs, etc.) I am using the Disk Quota function of Media Portal to save recordings until there is less than 2GB Disk space free, and currently the F: drive reports 4GB Free space. So, either something isn't being reported correctly, or older files aren't being discarded fast enough when the drive is filling up during recordings. Any other settings I can adjust to solve this?

Thanks

 

[mm1352000]

...or older files aren't being discarded fast enough when the drive is filling up during recordings.

I haven't checked the TV service log to confirm, but my guess is that this is correct.

The disk quota check seems to run every 15 minutes:
https://github.com/MediaPortal/Medi...vService/DiskManagement/DiskManagement.cs#L39

Recording an HD channel: ~10 Mb/s = 1.25 MB/s => 75 MB per min => 1.125 GB per 15 minutes.
Recording an SD channel: ~3 Mb/s = 0.375 MB/s => 22.5 MB per min => 337.5 MB per 15 minutes.

It would only take [for example] a couple of simultaneous HD recordings (or equivalent combination) to be using more than 2 GB per 15 minutes. In such a situation, it is entirely possible that the HDD would run out of space before the disk management logic deleted an old recording.

Any other settings I can adjust to solve this?

Sure. If the above theory is correct, a simple solution would be to modify the quota settings to leave more free space.

 

[Vasilich]

if timeshifting is configured to be also on F drive, then it can take additional space during timeshifting. Maybe @deamon_knight checked free space after stopping timeshifting (resulting in deleting all timeshift files, that can free some gigabytes on HDD), hence the difference 2GB/4GB