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

Steven Cruysberghs steven.cruysberghs at pi.be
Thu May 13 09:20:49 EDT 2004


Can't exactly remember when it was fixed. Have a look in the commits
archive or try disabling the preview video and see if it still happens.

Steven

> 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
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>



More information about the mythtv-users mailing list