[mythtv-users] Bug in "Watch Recordings" ?
Jason Donahue
mythtv at timekiller.org
Thu May 13 08:04:52 EDT 2004
Sorry for the long email, but there was a lot to say!! (Get comfortable)
I think I found a bug in MythTV, specifically in "Watch Recordings".
First let me explain my setup...
I have my master backend in my living room, with 2 CTV receivers hooked
up. The ringbuffer, and all recordings are stored on an NFS mounted data
server connected over cat 5. I also have a slave frontend in my bedroom,
coonected to the master backend over my 802.11G (54Mbps wireless). The
slave has no tuners defined, so to watch tv, I use an unused tuner on
the master backend, streamed wirelessly.
On the master backed I have little to no problems. However, I have been
noticing problems the slave in the bedroom. The video "stutters" like
there is not enough bandwidth on the wireless link to handle the stream.
It finally got to the point where I started troubleshooting. First off,
I KNOW the pipe is big enough for the stream, as I can watch live tv on
my laptop (802.11b - 11Mbps).
What I discovered was, if I reboot both boxes, and go into live TV on
the slave, everything works fine. For hours I can watch TV with no
hiccups. Then I go into "Watch Recordings" and it plays fine for a few
minutes, then starts stuttering. Now keep in mind, the recordings are
physically on my data server, NFS mounted on the master backend,
streamed over the wireless. At first I thought there was too much
latency in the network, but here is where it gets odd.
If I exit out of the recording, the network traffic does not die. Even
after 20 minutes of sitting at the main menu, the activity lights are
going nuts. I do some packet sniffing, and see myth traffic (port 6543)
going back to the master backend. Furthermore, I see a ton of NFS
traffic going between the master backend, and the data server. If I kill
the frontend and both boxes, the traffic stops. Next I tried it the same
thing on the master backend. If start watching a recording (stored on
the dataserver). The hub lights up, as expected. I exit out, and the
lights keep going! A tcpdump shows that it's all NFS traffic (the port
6543) traffic would not hit the wire, as the masterbackend is also the
frontend). If I kill the frontend, the traffic stops.
It seems like a few minutes into watching recordings, a huge amount of
"extra" packets are being generated, and don't stop, even if sitting at
the menu. There is no video stuttering on the master backend, presumably
because the 100Mbps line can handle the "extra" traffic. Unfortunately,
the wireless link can not. I did some bandwidth tests on that link, and
consistantly get 1.2Mbps through - more that plenty, so this additional
traffic must be a lot.
Now, here are some answers to questions I KNOW are coming:
1. My recordings are being recorded at the exact same bitrate as live TV
2. I am not transcoding the files afterwards
3. When I exit the recording, I am not sitting at the "preview" screen,
so the traffic is not coming from the thumbnail preview stream.
And here is a snip of the tcpdumps I took:
Sitting at the main menu, this is the traffic between the slave and the
master backend:
22:34:13.183065 10.2.100.5.6543 > 10.2.100.7.32780: . 3808:5256(1448)
ack 1 win 5792 <nop,nop,timestamp 107393 90608> (DF)
0x0000 4500 05dc 562c 4000 4006 02e0 0a02 6405 E...V, at .@.....d.
0x0010 0a02 6407 198f 800c 2c92 1d3b 27e7 addc ..d.....,..;'...
0x0020 8010 16a0 e61e 0000 0101 080a 0001 a381 ................
0x0030 0001 61f0 3282 b9ae b962 19d5 4e31 3de0 ..a.2....b..N1=.
0x0040 6300 1ae2 0810 e453 88c8 72ea b870 8c23 c......S..r..p.#
0x0050 f953 .S
22:34:13.183403 10.2.100.5.6543 > 10.2.100.7.32780: . 5256:6704(1448)
ack 1 win 5792 <nop,nop,timestamp 107393 90608> (DF)
0x0000 4500 05dc 562d 4000 4006 02df 0a02 6405 E...V- at .@.....d.
0x0010 0a02 6407 198f 800c 2c92 22e3 27e7 addc ..d.....,.".'...
0x0020 8010 16a0 0e2d 0000 0101 080a 0001 a381 .....-..........
0x0030 0001 61f0 731e 06af 1061 8441 b931 17dd ..a.s....a.A.1..
0x0040 39a8 3b05 e827 0f03 626c 03ae 1f07 2c8b 9.;..'..bl....,.
0x0050 779d w.
22:34:13.183424 10.2.100.7.32780 > 10.2.100.5.6543: . ack 6704 win 63712
<nop,nop,timestamp 90609 107393> (DF)
0x0000 4500 0034 103d 4000 4006 4e77 0a02 6407 E..4.=@. at .Nw..d.
0x0010 0a02 6405 800c 198f 27e7 addc 2c92 288b ..d.....'...,.(.
0x0020 8010 f8e0 d7da 0000 0101 080a 0001 61f1 ..............a.
0x0030 0001 a381 ....
22:34:13.183894 10.2.100.5.6543 > 10.2.100.7.32780: . 6704:8152(1448)
ack 1 win 5792 <nop,nop,timestamp 107393 90608> (DF)
0x0000 4500 05dc 562e 4000 4006 02de 0a02 6405 E...V. at .@.....d.
0x0010 0a02 6407 198f 800c 2c92 288b 27e7 addc ..d.....,.(.'...
0x0020 8010 16a0 12f7 0000 0101 080a 0001 a381 ................
0x0030 0001 61f0 0018 b365 0b38 78ba 3b0e 5054 ..a....e.8x.;.PT
0x0040 fe87 09b6 164e 1dc3 cf9c 098b d803 d967 .....N.........g
0x0050 600e `.
22:34:13.185640 10.2.100.5.6543 > 10.2.100.7.32780: . 8152:9600(1448)
ack 1 win 5792 <nop,nop,timestamp 107393 90609> (DF)
0x0000 4500 05dc 562f 4000 4006 02dd 0a02 6405 E...V/@. at .....d.
0x0010 0a02 6407 198f 800c 2c92 2e33 27e7 addc ..d.....,..3'...
0x0020 8010 16a0 a8ac 0000 0101 080a 0001 a381 ................
0x0030 0001 61f1 4918 5ec1 8bff e850 6871 e9b3 ..a.I.^....Phq..
0x0040 2810 62fa 530c ce22 d115 91ae 0000 0113 (.b.S.."........
0x0050 1224 .$
22:34:13.185657 10.2.100.7.32780 > 10.2.100.5.6543: . ack 9600 win 63712
<nop,nop,timestamp 90609 107393> (DF)
0x0000 4500 0034 103e 4000 4006 4e76 0a02 6407 E..4.>@. at .Nv..d.
0x0010 0a02 6405 800c 198f 27e7 addc 2c92 33db ..d.....'...,.3.
0x0020 8010 f8e0 cc8a 0000 0101 080a 0001 61f1 ..............a.
0x0030 0001 a381 ....
And here is a snip of the traffic between the master backend and the NFS
data server:
--
×·.¸¸.·´¨) ¸.·´ ¸.·´¨) O Jason Donahue
(_¸.·´ (¸.·´¸.·× O jdonahue at timekiller.org
(_¸.·´ O http://www.timekiller.org
More information about the mythtv-users
mailing list