2011/3/6 adq <adq@xxxxxxxxxxxxx>: > 2011/3/5 adq <adq@xxxxxxxxxxxxx>: >> 2011/3/5 Juan Jesús García de Soria Lucena <skandalfo@xxxxxxxxx>: >>> Hi, Andrew. >>> >>> This is what happens to me with both the KWorld dual tuner (when using only >>> one tuner) and the Avermedia Volar Black (single tuner), both based on >>> AF9015. >>> >>> I also got corrupted streams with the KWorld when capturing via both tuners >>> (the video our the audio would show artifacts in mythtv each several >>> seconds). >>> >>> As far as the loss of tuning ability goes, I think it's a problem related to >>> tuning itself, since it wouldn't happen when you just left a channel tuned >>> and streaming in a simple client, but would trigger after a random time when >>> you left mythtv scanning the channels for EIT data. >>> >>> I don't think it's a problem with a specific HW implementation, since I got >>> it with both AF9015-based cards. It could be either a chipset quirk our a >>> bug in the driver. >>> >>> My informal and quick tests with Windows Media Center and these cards did >>> not reproduce the problem, when trying to change channels as quickly as >>> possible, admittedly for not so long a time. >> >> Correct. I have two af9015 cards from different manufacturers as well, >> and they both exhibit the same problem. >> >> However, on a hunch last night, I went back to my original (-v1) patch >> with the total i2c bus lock and left it running with my tuning scripts >> for 10 hours. Both tuners are still working fine. That isn't >> conclusive, but it is encouraging. >> >> I'm just swapping back to a completely unpatched state to see how long >> it takes to break and to check if its easily reproducible (on my live >> system, it usually does it within a few hours of normal usage). >> > > Hi, right, I can reproduce it when completely unpatched, but it takes > a while. I left HTS "tvheadend" running at the same time as "dvbsnoop" > monitoring each frontend's status (so I had lots of i2c traffic going > on), and it happened sometime overnight. I turned on all the idle > scanning and frontend monitoring features tvheadend has. > > Now trying running the same with the -v1 patch. > Hi, its been running for well over 24 hours now, and its still tuning fine. I'm obviously I'm going to leave it testing for more days, but I'm daring it to suddenly break as soon as I send this mail :) As you will recall, v3 implemented a lock around the i2cgate so that only one frontend could open it and therefore only one could access a tuner at a time. Since this didn't fix the issue, it implies that if the gate is open *any* other i2c access (e.g. just reading the ucblocks) can somehow "crash" the tuner in such a way that it needs a hardware reset. This means you'd need a complete lock around *anything* which can cause i2c traffic as v1 implements (assuming v1 does fix it that is). Anyway, I'm keeping it running for the moment. It'd be good if someone else who experiences this problem could try out v1 too though. Oh, I see these every now and then: af9015: recv bulk message failed:-71 af9015: af9015_rc_query: failed:-1 dvb-usb: error -1 while querying for an remote control event. They don't seem to cause a problem, but seems odd they should occur at all. Disabling rc polling "fixes" it as docced elsewhere, but why do they occur in the first place I wonder? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
