[mythtv-users] Bug in "Watch Recordings" ?

Thu May 13 08:46:35 EDT 2004

I am running CVS version from (i believe) 3/31/04.

On Thu, 2004-05-13 at 08:19, Steven Cruysberghs wrote:
> Short answer to long mail :
> 
> if you are using .14 version this is probably the bug where the preview
> video from the "watch recordings" screen keeps playing in the background.
> This has been fixed in CVS.
> 
> > 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
> >
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> >
> 
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users