[mythtv] Transcoding before commercial flagging and bad PROTOCOL

Kevin Kuphal kuphal at dls.net
Thu Mar 16 14:40:07 UTC 2006


I have automatic commercial flagging set but I also have the checkbox in 
mythtv-setup checked to run transcoding first, before commercial 
flagging if selected.  With my new HD recorder, I have a frontend that 
cannot playback the content so I've been playing with transcoding.  The 
process itself works fine, but I've noticed that if I'm recording from 
the HD recorder, the commercial flagging starts despite the checkbox to 
tell it to wait. 

Has anyone seen this or can confirm that the checkbox does as instructed?

The reason I noticed this is because the flagging generates copies 
MPEG-2 errror messages and eventually puts my backend into a state where 
it fails to respond but the database continues to work, SSH is fine, and 
all other actions except the backend.  The log fills with stuff like this:

[mpeg2video @ 0x40e30670]invalid mb type in I Frame at 1 67
[mpeg2video @ 0x40e30670]skipped MB in I frame at 42 67
[mpeg2video @ 0x40e30670]skipped MB in I frame at 84 67
[mpeg2video @ 0x40e30670]00 motion_type at 42 65
[mpeg2video @ 0x40e30670]00 motion_type at 84 65
[mpeg2video @ 0x40e30670]00 motion_type at 7 66
[mpeg2video @ 0x40e30670]00 motion_type at 57 66
[mpeg2video @ 0x40e30670]00 motion_type at 82 66
[mpeg2video @ 0x40e30670]00 motion_type at 34 67
[mpeg2video @ 0x40e30670]00 motion_type at 44 67
[mpeg2video @ 0x40e30670]end mismatch left=574

but the transcoder doesn't report any errors like this and the 
transocded content appears fine.  On the frontend, when the backend is 
in this state, I get this:

2006-03-15 21:54:24.630 Connecting to backend server: 192.168.1.100:6543 
(try 1 of 5)
2006-03-15 21:54:44.635 ReadStringList timeout (quick).
2006-03-15 21:54:44.654 Unexpected response to MYTH_PROTO_VERSION:
2006-03-15 21:55:27.024 Connecting to backend server: 192.168.1.100:6543 
(try 1 of 5)
2006-03-15 21:55:47.030 ReadStringList timeout (quick).
2006-03-15 21:55:47.031 Unexpected response to MYTH_PROTO_VERSION:

Also, the backend fails to respond to XML queries on 6544 or any attempt 
to talk to it but it still reports Running Housekeeping (I haven't 
updated to that fix yet).  This has happened twice now, both times 
apparently when realtime commflagging was running on my HD recording.

For reference, my setup is HD recorder in slave backend writing 
recording via NFS to master backend.  I have tested recording 4 streams 
at once (3 SD from a PVR-500 and PVR-150 in the master and 1 HD from the 
slave) and I have no issues with that.  It only seems to happen with the 
realtime commflagging starts.  If I schedule 4 recordings and 2 jobs 
start commflagging the SD shows, no problem.  If I have only a single HD 
recording (like I did last night) and realtime commflagging starts, it 
takes down the backend with the logs above.  I do not run any jobs on 
the slave, all jobs run on the master backend with local access to the 
files.

I'm going to run a test on Friday to record a single HD recording with 
no commflagging but only transcoding to see what happens. 

For reference, my NFS mount is

mythtv:/usr/local/media /usr/local/media        nfs     
rsize=8192,wsize=8192,hard,intr,nfsvers=3 0 0

It's been that way for a long time but I'm not sure if there is 
something in that statement that might cause problems.  It doesn't seem 
likely since the problem only occurs when realtime commflagging starts 
on the master backend on an in progress HD recording from the slave.

Thanks,
Kevin




More information about the mythtv-dev mailing list