[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