Re: [pvrusb2] WinTV USB2/Tv-Viewer question
On Thu, Aug 29, 2013 at 8:24 PM, Roger wrote: > 1) Power Supply (Likely older models?) - Lost my old PVRUSB2 Model #29061 > because I think the power supply shorted-out, and the power strip surge > protector likely could not handle this scenario. Oddly, this scenario very > likely tripped two separate breakers in the house just as I heard a very loud > pop noise! Not just the breaker of the house circuit the PVRUSB2 device was > on, but the bedroom as well. By any chance was there a transformer load in the Bedroom? Or something else with "high" power requirements, like a large air conditioner? When the voltage(s) change rapidly (such as a short), there can be a current surge as a transformer (or motor) field collapses. In theory circuit breakers are supposed to handle inrush/outrush currents, but in theory, theory and practice are the same, and in practice, they are not. Gary ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] WinTV USB2/Tv-Viewer question
> On Thu, Aug 29, 2013 at 12:01:47AM -0500, Mike Isely wrote: > >I have over time seen some reports where people have gotten frequent rapid >bursts of this problem happening. In all cases that I remember, it was never >pinned down to be a real encoder problem. Rather some have found that >cleaning up glitchy power has helped - the mpeg2 encoder is probably the most >complicated and definitely the most power hungry chip in the device so it >might be the most power sensitive as well. It might also be a sign over >overheating. I've also suspected over time that if the mpeg encoder fails to >get a "clean" digital stream from the upstream pipeline stage (the video >digitizer) - perhaps because of problems with video sync - that this might >cause the mpeg encoder to behave badly. But I've never been able to prove it. My votes for all three of these possible causes. 1) Power Supply (Likely older models?) - Lost my old PVRUSB2 Model #29061 because I think the power supply shorted-out, and the power strip surge protector likely could not handle this scenario. Oddly, this scenario very likely tripped two separate breakers in the house just as I heard a very loud pop noise! Not just the breaker of the house circuit the PVRUSB2 device was on, but the bedroom as well. Happened more than a year ago, and never again. Shortly there after I found the PVRUSB2 the only disfunctional device within those two circuits. (I probably should have tested the unit to see if it were still good using a known good power supply, but the cost of the power supply would have costed just as much as a new device.) 2) Poor RF Reception/Tuning - However as Mike has already speculated, I think I've also seen this reset with poor reception as well. Too much interference within the signal requiring more processing of the signal to rasterize static or poor reception. However, could be related to power supply or overheating. 3) Hardare Level Bugs - Also as already speculated, when no source of the problem can be found, it usually is found to lie within the proprietary code. Darn good devices. But it only takes one part of a device containing a million components for it to fail. Sounds like your device is a newer model. -- Roger http://rogerx.freeshell.org/ ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] WinTV USB2/Tv-Viewer question
Oh... sorry this is a little off topic for this forum, but... I broke down and bought a HDHomerun hardware. The digital quality output is amazing. In theory, since I can play it via VLC, I should be able to redirect that to a file from the command line right? I would just need to know the IP address, port # etc, then just redirect (>) to a file yes? From: Mike Isely To: Communications nexus for pvrusb2 driver Sent: Wednesday, August 28, 2013 10:01 PM Subject: Re: [pvrusb2] WinTV USB2/Tv-Viewer question On Tue, 27 Aug 2013, Lorne Shantz wrote: > I have done some more tinkering... It seems to be related to the composite > cables coming from the vcr player. ? Tv-viewer would not play. I'm getting a > lot of this below: > > > [19727.089020] pvrusb2: ***WARNING*** device's encoder appears to be stuck > (status=0x0003) > [19727.089023] pvrusb2: Encoder command: 0x81 > [19727.089024] pvrusb2: Giving up on command. This is normally recovered via > a firmware reload and re-initialization; concern is only warranted if this > happens repeatedly and rapidly. > > Routinely testing, I removed the cables from the vcr player and up it comes. > ?? So it is intermittent it seems. I have recorded stuff from the vcr, but > something seems amiss. Is there such a thing as a firmware update for these > devices? > I have over time seen later versions of the mpeg video encoder firmware bundled with later models of the device (any of the devices, actually). The fwextract.pl script recognizes a number of variants. However I personally have never really seen any improvement (or degradation) in behavior of that encoder correlated with firmware revision. Generally speaking, the different mpeg encoder firmware variants floating around all seem to be interchangeable, and the pvrusb2 driver doesn't make any attempt to discriminate among them. As for the "...apears to be stuck..." message, that is what happens when the pvrusb2 driver attempts to issue a command to the mpeg encoder and the encoder fails to acknowledge it. (There's a sort of shared memory mailbox interface which uses a sort of handshake protocol for issuing commands to the encoder.) From all outward behavior at this point, the encoder appears to be crashed. I've only ever seen this happen when the command is issued to start streaming and there has NEVER been any pattern to it that I could find. It's just generally been random with a low probability. The pvrusb2 driver always recovers this case by quickly reseting the encoder and reloading its firmware. It's hackish but the whole recovery happens in less than a second and because it only ever seems to happen when streaming is started, it never actually causes lingering problems. Back when I first encountered this behavior (way back around 2005) I spent a LONG time trying to characterize it so that I could understand its cause. I never did find the root cause. Instead, the workaround (i.e. reboot the encoder) all along seems to have been good enough. Some day if I could ever get a good look at the source code for that encoder firmware, it might be possible to finally suss out what's really going on. But I doubt that day will ever come :-( I have over time seen some reports where people have gotten frequent rapid bursts of this problem happening. In all cases that I remember, it was never pinned down to be a real encoder problem. Rather some have found that cleaning up glitchy power has helped - the mpeg2 encoder is probably the most complicated and definitely the most power hungry chip in the device so it might be the most power sensitive as well. It might also be a sign over overheating. I've also suspected over time that if the mpeg encoder fails to get a "clean" digital stream from the upstream pipeline stage (the video digitizer) - perhaps because of problems with video sync - that this might cause the mpeg encoder to behave badly. But I've never been able to prove it. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] WinTV USB2/Tv-Viewer question
Speaking of draw... are there any recommendations for a power supply other than the original? I'm assuming 6volt DC, + center pole, 1amp +? I'm leaning away from a power supply problem, but it can't hurt to positively eliminate that as a potential. From: Mike Isely To: Communications nexus for pvrusb2 driver Sent: Wednesday, August 28, 2013 9:45 PM Subject: Re: [pvrusb2] WinTV USB2/Tv-Viewer question Technically speaking the composite input actually uses *less* of the tuner than the RF input. It's one less pipeline stage. However there's nothing that controls power to the RF section so I would expect the power draw to be no different. On the whole the mpeg encoder chip is probably drawing the majority of the power anyway, so any difference in whether or not the RF tuner is actually doing any work probably makes no difference at all. If there's any difference at all, I would guess that a clean (i.e. no video noise) signal would probably present less work to the mpeg encoder and so might lower the power draw overall - which would suggest again that the composite input would be an improvement over RF since weak signals / interference / other sources of noise wouldn't get in the way. But that's really just a wild guess. -Mike On Wed, 28 Aug 2013, Gary Buhrmaster wrote: > On Wed, Aug 28, 2013 at 7:50 PM, Lorne Shantz wrote: > > Hmmm... so you think it is drawing more power to pull the signal from the > > vcr machine? It is rock solid (it seems) when capturing TV signal, or > > watching tv. > > Well, it really should not (be significantly different), but my first reaction > to "flaky" is always to check the power (source). It is an old habit > from long ago lessons. > > Gary > ___ > pvrusb2 mailing list > pvrusb2@isely.net > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] WinTV USB2/Tv-Viewer question
Hey Mike, Thanks for the reply After playing with it for a couple of days now, I feel fairly confident that this issue is an application issue. I can view vcr tape fine, and I can view tv fine. I seem to be able to record tv fine, but only part time can I record vcr. I will learn more as I tinker until I can find a better solution to recording. Just simply doing the bash prompt command seems stable as suggested by one of our readers... So I DO have a work around for now. From: Mike Isely To: Communications nexus for pvrusb2 driver Sent: Wednesday, August 28, 2013 10:01 PM Subject: Re: [pvrusb2] WinTV USB2/Tv-Viewer question On Tue, 27 Aug 2013, Lorne Shantz wrote: > I have done some more tinkering... It seems to be related to the composite > cables coming from the vcr player. ? Tv-viewer would not play. I'm getting a > lot of this below: > > > [19727.089020] pvrusb2: ***WARNING*** device's encoder appears to be stuck > (status=0x0003) > [19727.089023] pvrusb2: Encoder command: 0x81 > [19727.089024] pvrusb2: Giving up on command. This is normally recovered via > a firmware reload and re-initialization; concern is only warranted if this > happens repeatedly and rapidly. > > Routinely testing, I removed the cables from the vcr player and up it comes. > ?? So it is intermittent it seems. I have recorded stuff from the vcr, but > something seems amiss. Is there such a thing as a firmware update for these > devices? > I have over time seen later versions of the mpeg video encoder firmware bundled with later models of the device (any of the devices, actually). The fwextract.pl script recognizes a number of variants. However I personally have never really seen any improvement (or degradation) in behavior of that encoder correlated with firmware revision. Generally speaking, the different mpeg encoder firmware variants floating around all seem to be interchangeable, and the pvrusb2 driver doesn't make any attempt to discriminate among them. As for the "...apears to be stuck..." message, that is what happens when the pvrusb2 driver attempts to issue a command to the mpeg encoder and the encoder fails to acknowledge it. (There's a sort of shared memory mailbox interface which uses a sort of handshake protocol for issuing commands to the encoder.) From all outward behavior at this point, the encoder appears to be crashed. I've only ever seen this happen when the command is issued to start streaming and there has NEVER been any pattern to it that I could find. It's just generally been random with a low probability. The pvrusb2 driver always recovers this case by quickly reseting the encoder and reloading its firmware. It's hackish but the whole recovery happens in less than a second and because it only ever seems to happen when streaming is started, it never actually causes lingering problems. Back when I first encountered this behavior (way back around 2005) I spent a LONG time trying to characterize it so that I could understand its cause. I never did find the root cause. Instead, the workaround (i.e. reboot the encoder) all along seems to have been good enough. Some day if I could ever get a good look at the source code for that encoder firmware, it might be possible to finally suss out what's really going on. But I doubt that day will ever come :-( I have over time seen some reports where people have gotten frequent rapid bursts of this problem happening. In all cases that I remember, it was never pinned down to be a real encoder problem. Rather some have found that cleaning up glitchy power has helped - the mpeg2 encoder is probably the most complicated and definitely the most power hungry chip in the device so it might be the most power sensitive as well. It might also be a sign over overheating. I've also suspected over time that if the mpeg encoder fails to get a "clean" digital stream from the upstream pipeline stage (the video digitizer) - perhaps because of problems with video sync - that this might cause the mpeg encoder to behave badly. But I've never been able to prove it. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] WinTV USB2/Tv-Viewer question
Am 29.08.2013 00:04, schrieb Lorne Shantz: It is building the file and I can actually watch it as it is building since Linux doesn't lock files like Winbloze. On Windows an applications needs to explicitely allow shared access. For example you can say that your application has read/write access while others may only read. Unix based systems and Windows simply have different approaches to file locking whereby each has its pros and cons. See also here: http://en.wikipedia.org/wiki/File_locking Regards, Sven ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
