svn 8210 -> 8235 breaks some channels (zero byte recording)

[tephra@…]

Hi All,

I have been lax in my svn updates recently, today I updated from 7857 to 7974 and some channels dont record anymore - I just end up with a zero byte file.

mythbackend -v all are attached for a working and borked. ( as soon as i work out how to attach them! )

I am doing a channel rescan now just incase new PID's or something?!?!

Cheers Dave

[tephra@…]

Broken Recoding

[tephra@…]

A working record of a different channel.

[tephra@…]

Hi All,

ok i updated to 7901 and from 7857 and its still all ok.

7919 didn't work however so it must be a change in between there.

Once I know which commit breaks it i will post back :) i think it might be DK's 7902 :)

cheers dave.

[torbjorn.jansson@…]

i'm also having this problem, since i updated on i think sunday. shows recorded on my dvb card gets created as zero length files.

i tried to find the problem yesterday but didn't find anything obvious in the logs from the backend. but, i was able to get livetv to work and atleast once switch channel on my dvb card, so i do get some data from.

[danielk]

Can someone check this with current SVN?

I fixed some zero length recording problems on Monday.

[tephra@…]

Nope is still borked with 8029. attached mythbackend -v all.

Cheers Dave

[Jon Whitear]

I'm getting the same thing (8027.) I can record one channel (SBS) but all others give zero byte recordings. This results in a segfault on Live TV if the starting channel is a problematic one.

[danielk]

Jon, can you make a log of the backend with "-v record,channel,siparser,file" then start a recording on one of these channels (not a livetv recording), leave it running for 90 seconds, then stop the recording. Then attach the entire log to the ticket.

[teemu.sillanpaa@…]

Same problem here (8035). The log with option -v record,channel,siparser,file is at url: ​http://www.itcasi.com/yksityiset/teemu.sillanpaa/mythbackend_zero_size_recording.log

It was too big to attach...

Teemu

[Jon Whitear]

Mythbackend log (zero byte recording from channel 10)

[Jon Whitear]

Backend log attached as requested, though I see Teemu beat me to it! It ran for a little longer than 90 seconds, as I got called away. The recording was scheduled through mythweb, then I restarted the backend to get a clean log. The recording was also stopped (by deleting it) though mythweb, though I've snipped those lines.

Cheer,

Jon

[anonymous]

temmu, what does "ls -l /opt/pub/mythtv/1017_20051124213600.mpg" give you? jon, I would ask you the same, but you say you deleted the recording...

The recordings looked like they were started up properly, I don't understand why it didn't work..

If you could find the specific changeset that breaks the recordings that might help.

[Jon Whitear]

Here's what I get in my video directory for a show that recorded on channel 10, starting at 18:30, and finishing at 17:05.

server root # ls -l /var/media/video/1010_20051125* -rw-r--r-- 1 root root 0 Nov 25 18:30 /var/media/video/1010_20051125183000.mpg

I upgraded from 7738 (or whatever the pre-broken-live-tv release was) to 7936, but only got backend segfaults (ticket 684.) They were fixed in 7959, but Live TV didn't work for me at that release.

[tephra@…]

well as I said my svn is upto 7901 and that works correctly - however 7919 is broken.

ive updated the title to reflect this :) when i have time i will go through 7901 -> 7919 to find out which chg breaks it :)

[ch@…]

7902 seems to be the problem. 7901 works, the zero byte recordings appear with 7902

​http://cvs.mythtv.org/trac/changeset/7902

[danielk]

Can either of you try two these two things:

• Try increasing search windown value in FindKeyframes?() replace the 10 in return (idx >= 10*TSPacket::SIZE); with 100.
• Try Stuart's [7902] revert patch attached to ticket #692.

Hopefully increasing the search window is sufficient. If not, then hopefully reverting 7902 works.

-- Daniel

[tephra@…]

Hi Daniel,

8035 with 7902 revert works.

most recent SVN with 10->100 didn't do anything :)

Hope this helps.

Cheers Dave

[anonymous]

Dave, this definately helps.

I'll revert [7902] and then e-mail you with the info I need for testing a better fix for #659.

[danielk]

(In [8042]) References #689.

Reverts [7902] until we can figure out why it isn't finding keyframes on some streams.

[danielk]

(In [8126]) References #689.

When looking at this I noticed that David Shirley's recording had some PMT problems. This should fix that problem by generating the PMT differently and by incrementing the continuity counter when needed.

[danielk]

(In [8211]) Fixes #659 again (broken by [8126]) and fixes #689.

This is reapply of [7902] updated to the latest SVN. It should no longer cause #689, because that seems to have been due to the a bad interaction with the bug fixed in [8080].

[tephra@…]

Hi All,

I think its 8211 but i didn't have time to test it fully.

backend log attached.

Cheers Dave

[tephra@…]

SVN 8235 backend log of zro byte recording.

[danielk]

(In [8258]) References #689.

I don't think this is causing the zero byte recordings, but it could be a contributing factor. Basically, if the PES header code straddles TS packets in a certain way the scanner could have missed them before this change. Also I made the frame tracking variables unsigned, except the first_keyframe variable which is now set to -1 before it is set. This lets us eliminate a couple variables and simplify the code further.

[danielk]

Can you try this patch?

[tephra@…]

Hi Daniel,

I loaded up 8272 last night and that appeared to work fine. I am not sure if its something to do with what they are Bcasing (ie widescreen, or not...).

I am going on leave for a while so I won't be able to test things out until I get back.

Cheers Dave

[danielk]

(In [8290]) Fixes #689, fixes #816. Don't abort the scan for pictures too early...

Torbjorn Jansson actually reported to me that an earlier fix for #689 appeared to have worked for him. But this fixed a final problematic stream of David's so I'm closing this ticket with this commit. #816 appears to be a result of this same bit of code, basically if the picture code was transmitted too long after the seq or gop it wouldn't be found. This is sort of the exact opposite of the problem in #799.