On Sun, 25 Jan 2009, Alex Betis wrote: > On Sun, Jan 25, 2009 at 6:29 PM, Hans Werner <HWerner4@xxxxxx> wrote:> > > On Sun, Jan 25, 2009 at 4:41 PM, Hans Werner <HWerner4@xxxxxx> wrote: > > > > > If you have a stb0899 device, don't forget to add "-k 3". > > > > Oh. Can someone say what's different about the stb0899 here,> > > > and how -k 3 helps ? > > > stb0899 driver (or maybe the chip?) has some buffers inside that are not> > > reset between tunnings.> > > In that case messages from *previous* channel will arrive after the> > > tunning> > > to new channel is complete.> > > Those messages will create a big mess in the results, such as channels> > > without names, duplicate channels on different transponders.> > > -k option specifies how many messages should be ignored before processing> > > it. I couldn't think of a more elegant way to ignore messages from> > > previously tuned channel. I use "-k 3" by myself, but after playing> > around> > > with "-k 2" saw that its also working. "-k 1" was still not enough. > > OK, thanks, I will check if I see that problem. Which card(s)> > did you see this with? > I'm aware only about Twinhan 1041 and TT-3200 based stb0899 cards. Both have> the same problem. This may be going typically off-topic, but I do experiencesimilar artifacts with some STV0299 cards (looks superficiallyalike; I don't know), which I'll toss out here just for giggles. It turns out I have three if not four such stv0299 cards, andI either experience `scan' difficulties or recording issues,or nothing. First off, for reference: a PCI SkyStar2 card that getspriority for recordings, using a 2.6.14-ish kernel that I'min the long slow process of planning to update on thatproduction machine. When making two recordings separated by time from the sametransponder, often the second recording will have a fewvideo frames left over from the previous recording. Thisappears in my quality-control as video frames with differingtimestamps as well as errors when run through `mplayer'video codec ffmpeg12, but timing data remains intact (I can`dd' away the first second or more and get a flawlesspartial transport stream). This is not a problem when I switch between transpondersto make the second recording. And it can be many hoursbetween recordings from the same transponder, yet theleftover data still remains. I've never noticed that this affects `scan' which changestransponders; that in itself seems to be enough to losethe buffered data. This is only a minor concern as thefirst few frames of confused data are almost certainlydisposable, as a fraction of a second in the paddingleading up to the content of interest. As exhibit number two, where I have had problems withregular `scan' seeing data from the previous transponderand causing problems getting current data, anotherstv0299-based device, the Opera-1 USB-connected tuner.I have *never* seen any recordings made from thisdevice contain frames from an earlier tuning session,though. As far as `scan' tuning goes, I would regularly seeprevious ``phantom'' channels appearing, combined withzero-value PIDs for channels on the intended currenttransponder. At least until recently; my latest scanshave been flawless, either due to hacks I added tothat `scan' or to kernel updates on that test machine. Exhibit C, m'lud, will be -- again on the 2.6.14-ishkernel machine, but this time connected via USB 1.1 --an early Nova-S device. Apart from bandwidth issuesdue to the usb1 interface, I've never noticed problemswith stale packets when recording from either the sameor a different transponder. I do have other issueswhich may be due to the age of the kernel, but `scan'also has not had problems. Now with exhibit IV, again I see problems similar tothose experienced with leftover packets, but whichappear to be compounded by the internal mangling ofthe transport stream components into a proprietary-yet-open delivery stream. This device is the ttusb-dec DEC3000-s, of unknown-based-on-kernel-codeheritage, though I may have taken it apart long agoand written the results on a long-since hidden drive. This device is connected via USB1, and is incapableof delivering more than an MPEG2 video and mp2 audiostream to a recording, making it useless for multipleaudio, teletext, AC3, H.264, or PMT tables to start. It also internally converts the transport streaminto the PVA format, with side-effects such as thatthe timestamps do not match the original transportstream components, cycling after some 40 000 secsrather than the 90 000-ish seconds delivered in thestreams from other devices. Recordings from this device all-too-often would havetiming problems as well as leftover data from aprevious recording. (Whether from same or differenttransponder, I cannot say. I added a hack-workaroundto my recordings to tune briefly a different txp,then tune back. Sometimes it worked. Often withhigh load, nothing could help.) Sometimes the timingwould be based on the leftover video data and wouldincrease linearly from that, being well out-of-stepwith the audio timing. Other times the video datatiming would be stuck at a non-increasing value.Obviously this caused major problems with utilitieslike `mplayer' which try to skew the presentation ofthe data until the timestamps match; other applicationscould better (though not perfectly) handle some datawith botched timestamps and at least display awatchable video with consistent sub-second audiooffset. Yet, a few recordings from this device would havethe video data totally corrupt and unrecoverablewithout great and pointless effort. Anyway, thetiming issues even when correctly recorded aspartial transport streams cause problems seekingwith `mplayer' at times, so basically I limit anyuse of this device nowadays to audio recordingswhere timing doesn't matter after being stripped toa simple mp2 file, and even then, often this devicecan't recover from a temporary loss of a quality signal(heavy rainstorm, half a metre of snow on the LNB)so, well, yeah. Use of `scan' was made using this device in thedistant past; I neither remember blatant problemsnor obvious successes other than issues with oneparticular device with the BSkyB Open-dedicatedtransponders. It generally works recording radiounless it's somehow half-bricked itself needing apower-off, but due to the timing issues andoccasional botched video recording, I've avoidedusing it for anything else for quite a few monthsnow. This device is used regularly to record audio, anddue to the nature of its tuning, I generally needto specify an unused PID as video, lest a previously-used video PID carry over to a different transponder(or the same) and add many times over the bulk tothe recording. Not so much an issue since I'veavoided it for video recordings... I've had a few cases recently where due to whateverreason (power failure, use of `kill'), the previousrecording from this device has not been closedcleanly. The next recording made, then has severalseconds worth of leftover audio. Often this willprecede the desired audio at a different bitrate.In order to skip the stale data, I'll need to `dd'the file with a `skip=' parameter, else my playerwill fail to detect the change. For audio recordingsthe last few which have had this problem have beencoarsely ``fixed'' by a value of `skip=1200', withtransport stream frame blocksize `bs=188'. Whether this value transfers to video, I cannotsay. Generally I prefer to lob off the minutesworth of padding I provide to accommodate programmeover-/under-running and similar last-minute changes,than to worry about an uninteresting stream. Thelower bandwidth of audio makes a tweak of 100 TSframes more meaningful and easier to handle. As a side note that eventually, as part of my slowprogress in updating the 2.6.14-ish machine to therequirements of today's Real World (use of flashstorage via USB for the entire OS has successfullypassed the one-month-without-panic mark and is nowpoised for widespread adoption), I've also noticedthat at least with the .14-ish kernel, and perhapson the test machine with .18-era, I have not beenable to get this plus the other USB1 device tocoëxist and simultaneously function via the samebus, getting a panic when using both devicessimultaneously. I intend to verify this with afar-more-recent kernel before complaining loudly. Note that in general, shared use of a USB1 portshould not cause me problems, as I've pretty muchlimited use of my USB1 devices to lower-bandwidthradio streams, or to a handful of channels whosebandwidth never approaches that of DVD-quality;that is, generally non-german-public-broadcasters. Wow, I'm able to talk about nothing for minutes onend. Too bad I can't type so fast and spend theremaining time coding something useful... barry bouwsmascum _______________________________________________linux-dvb users mailing listFor V4L/DVB development, please use instead linux-media@xxxxxxxxxxxxxxxxxxxxxxxx@linuxtv.orghttp://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
