Well, perhaps the hang-while-watching-recording is not completely Myth's fault: It just occured while I was looking for something else with dmesg.
I get a large amount of the following messages: ivtv0 warning: DEC: Sched Buffer end reached 0x0488efe4 ivtv0 warning: DEC: Mailbox 10: 0x00000000 0x0487efe4 0x0487efe4 0x0487efe4 ivtv0 warning: DEC: Sched Buffer end reached 0x0488efe4 ivtv0 warning: DEC: Mailbox 10: 0x00000000 0x0487efe4 0x0487efe4 0x0487efe4 ivtv0 warning: DEC: Sched Buffer end reached 0x0488efe4 ivtv0 warning: DEC: Mailbox 10: 0x00000000 0x0487efe4 0x0487efe4 0x0487efe4 ivtv0 warning: DEC: Sched Buffer end reached 0x0488efe4 ivtv0 warning: DEC: Mailbox 10: 0x00000000 0x0487efe4 0x0487efe4 0x0487efe4 Regards, Stanley. > > Hi Hans, > > I have been running 0.4.6 from almost the moment you asked us to test it. > > I'm having no problems at all with a P4, Hyperthreading enabled, on Debian > with a self compiled 2.6.15 kernel, 2 PVR350's and MythTV 0.19-fixes. > I do occasionally experience a lockup while watching a recording, but this > looks like it happens when a Myth recording ends or a new one starts while > watching another. > This is most likely a Myth problem, as currently I can fix this by > pressing Esc and then Enter to carry on playing, Myth 0.18 did a real hard > lockup (power cycle required). Do not have sufficient logs to report to > the MythTV list(s)... > > One clear difference I do notice compared to 0.4.5 when changing channels > in Myth LiveTV: > > (sequence of events:) > 0.4.5: > press key to change channel > display freezes for ~2 seconds > display runs for ~.5 second > display freezes > channel changes > > 0.4.6: > press key to change channel > display freezes for ~2 seconds > display runs for ~.5 seconds > display freezes > display runs for ~.5 seconds > channel changes > > So with 0.4.6 it seems to take slightly longer to change the channel and > the channel actually changes while video is running. In 0.4.5 the channel > change only occurs when the video is frozen. > > I suspect this is (partly?) caused by Myth, as the behaviour experienced > in 0.4.5 was introduced by a MythTV update, not by an ivtv update. But > perhaps some (subtle) change in ivtv activated/worsened this behaviour in > Myth? > > I do recall a thread not so long ago about not needing to stop the decoder > when changing channels... Could this be related?? > > Thanks for the good work! (how's the budget for the new monitor coming > along? still need donations? ;-) > > Regards, > Stanley. > > > >> Hi all, >> >> I'd like people to have a go with the 0.4.6 and 0.6.3 development >> snapshots available here: >> >> 0.4.6: >> http://ivtvdriver.org/viewcvs/ivtv/branches/0.4.tar.gz?view=tar >> >> 0.6.3: >> http://ivtvdriver.org/viewcvs/ivtv/branches/0.6.tar.gz?view=tar >> >> The channel changing problem should be fixed now (and should be a bit >> smoother too as the encoder is no longer paused/resumed). Please let me >> know if there are still problems with it. Also test if you didn't have >> problems before: it's done differently now (similar to what Hauppauge >> does) so if I'm unlucky it might break something that used to work :-( >> >> There are two pending issues that I'd like to solve before I make >> another release: 0.4.6 contains support for cx25840 sliced VBI for >> NTSC: I get conflicting reports on whether it works or not. >> >> The second issue is a problem with the i2c bus and tveeprom. This is the >> blocking bug that I'd really like to fix before doing a release. >> >> Thanks, >> >> Hans >> >> _______________________________________________ >> ivtv-devel mailing list >> [email protected] >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel >> > > > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
