Opened 14 years ago

Closed 13 years ago

#689 closed defect (fixed)

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

Reported by: tephra@… Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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

Attachments (6)

borked (21.9 KB) - added by tephra@… 14 years ago.
Broken Recoding
working (19.5 KB) - added by tephra@… 14 years ago.
A working record of a different channel.
still borked - 8029 (52.7 KB) - added by tephra@… 13 years ago.
backend.log.zero-byte-recording.txt (21.7 KB) - added by Jon Whitear 13 years ago.
Mythbackend log (zero byte recording from channel 10)
borked-8234 (15.8 KB) - added by tephra@… 13 years ago.
SVN 8235 backend log of zro byte recording.
689.patch (608 bytes) - added by danielk 13 years ago.
Can you try this patch?

Download all attachments as: .zip

Change History (29)

Changed 14 years ago by tephra@…

Attachment: borked added

Broken Recoding

Changed 14 years ago by tephra@…

Attachment: working added

A working record of a different channel.

comment:1 Changed 13 years ago by 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.

comment:2 Changed 13 years ago by 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.

comment:3 Changed 13 years ago by Isaac Richards

Owner: changed from Isaac Richards to danielk

comment:4 Changed 13 years ago by danielk

Milestone: 0.19
Version: head

Can someone check this with current SVN?

I fixed some zero length recording problems on Monday.

comment:5 Changed 13 years ago by tephra@…

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

Cheers Dave

Changed 13 years ago by tephra@…

Attachment: still borked - 8029 added

comment:6 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by 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.

comment:8 Changed 13 years ago by 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

Changed 13 years ago by Jon Whitear

Mythbackend log (zero byte recording from channel 10)

comment:9 Changed 13 years ago by 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

comment:10 Changed 13 years ago by 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.

comment:11 Changed 13 years ago by 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.

comment:12 Changed 13 years ago by tephra@…

Summary: svn 7857 -> 7974 breaks some channels (zero byte recording)svn 7901 -> 7919 breaks some channels (zero byte recording)

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 :)

comment:13 Changed 13 years ago by ch@…

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

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

comment:14 Changed 13 years ago by 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

comment:15 Changed 13 years ago by tephra@…

Hi Daniel,

8035 with 7902 revert works.

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

Hope this helps.

Cheers Dave

comment:16 Changed 13 years ago by 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.

comment:17 Changed 13 years ago by danielk

(In [8042]) References #689.

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

comment:18 Changed 13 years ago by 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.

comment:19 Changed 13 years ago by danielk

Resolution: fixed
Status: newclosed

(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].

comment:20 Changed 13 years ago by tephra@…

Resolution: fixed
Status: closedreopened
Summary: svn 7901 -> 7919 breaks some channels (zero byte recording)svn 8210 -> 8235 breaks some channels (zero byte recording)

Hi All,

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

backend log attached.

Cheers Dave

Changed 13 years ago by tephra@…

Attachment: borked-8234 added

SVN 8235 backend log of zro byte recording.

comment:21 Changed 13 years ago by 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.

Changed 13 years ago by danielk

Attachment: 689.patch added

Can you try this patch?

comment:22 Changed 13 years ago by 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

comment:23 Changed 13 years ago by danielk

Resolution: fixed
Status: reopenedclosed

(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.

Note: See TracTickets for help on using tickets.