Hans Meine wrote: > Hi Duncan! > > (I sent this mail this afternoon from work, but it did not make it to the > list, probably due to the sending address.) > > Am Mittwoch, 28. März 2007 08:43:44 schrieb Duncan Webb: >>> 1.) Often, a TV program is broadcasted with a second channel for blind >>> people, >>> narrating what happens on screen. Such recordings are recorded here with >>> both channels mixed into each other [...] >> IIRC the ivtv-0.8 and above correctly separates the audio channels and so >> I wrote the bilingual plug-in so you can choose with channel to listen to. > > Ah, another reason why it would make sense for me to try again with a more > recent kernel version. (Which is needed for ivtv-0.8+.) > >>> I checked that this was no Freevo problem by recording (/playing) >>> directly from /dev/video0, which also showed the problem so I decided to >>> upgrade ivtv. >> xine and embedded vbi data does not work well together, mplayer has no >> problem with vbi. The top third of the screen shows green blocks. > > Ah, vbi data. That's a hint. Alas, I tried with mplayer and that exhibited > the same errors. Another reason could be nxtvepg, which I have running now > since the end of January, which might as well be the point in time where the > visual artifacts began. nxtvepg seems to be more well-tested with > traditional v4l than with v4l2. BTW: The green blocks are within Xine only, > right? And I think my blocks are not always green, but I will have to check > that again.
Embedded vbi data and xine are the only problem I've seen. >> The best way to check this is to push the mpeg file into /dev/video16 and >> see what comes out of the scart interface (PVR-350 only, which your >> using). > > Hmm, that would be another idea for playback, right? But I have already > tried > the files with mplayer on several computers, so I am sure the problem is > within the file. (The scart interface is not connected, and the computer is > fit neatly into a furnature and not easy to access from behind... ;-/ ) > >>> 3.) [...] >>> scheduled >>> recordings end prematurely. That is - a program with 90 minutes might >>> end after 34 or only 11 minutes. Freevo shuts down (using the >>> autoshutdown plugin) after the correct time, i.e. it "waits" the rest of >>> the time without >>> the recorded file growing any more. [... I] think it is an ivtv >>> problem. >> >> May be, the XMLTV data is not always correct. Are the truncated recording >> happening over midnight? > > No, any time during the day and the EPG is fine (also I am now using nxtvepg). I haven't noticed any problems with truncated recordings and I use nxtvepg too. >> You may be able to see something in the recordserver log, it should report >> the start and stop times and if the recording has been killed by freevo. > > The logs looked fine to me, and as I wrote above, it looks as if Freevo > believes that the recording is still in progress. I made some recordings > this night and will check the logs for stop times again (last time I found > only start times IIRC). Which recording plug-in do you use? I use vbi2srt, as it uses the VPS data for recordings (only available in DE, AT and CH) >>> 4.) In parallel, I tried Linux-2.6.20.1 (I have the same kernel running >>> successfully on several other computers) with ivtv-0.10.1. Here, the >>> recordings are not fluent, but every half a second to second, the video >>> stops >>> which makes all movements appear jerky. The audio is fine though. [...] >> >> I saw something in the mythtv wiki about setting PCI latencies for the >> hard disk, this may help to ensure that the hard disk has sufficient >> response for recordings. http://www.mythtv.org/wiki/index.php/PCI_Latency > > That's a very interesting hint, thanks. I will check and report back, maybe > the Linux kernel sets different default PCI settings. Easy to check and I > will try changing the HD values, too. Must admit I can't change these values on my test machine. >> I must say that as far as I can see there haven't been any real >> improvements with the ivtv driver. I sort of have the feeling that the >> quality has dropped a bit with later versions. I'm pretty sure that recent >> recordings do not have quite the same quality as older recordings. > > My wife expressed the same feelings about a quality drop, but it's so hard to > verify. :-( Strange that nobody has reported this one the ivtv list, maybe it's time for a quick post on the ivtv list. Trouble is that this could be either the driver or the firmware, I would suspect the firmware as the driver is really only a wrapper on the firmware. But I think I still have 2.6.15 kernel and the old firmware, so I can test against this. >> But >> this could be because I have swapped the PVR-350 for a 500. The 350 is now >> in my test machine and I don't watch anything that I have recorded there. >> Having said this I did copy a couple of recordings across to the main >> machine and they were as jumpy as hell. > > Did I understand you correctly? Can you reproduce problem number 4 I have? > Sorry, but that's great! ;-)) :) Yes. A recording from this evening, with the PVR-350 has better picture quality than with the PVR-500 card but is really too jerky to watch. > It may take some time until I post an update about my findings. Thanks for > your feedback so far. I'm off on holiday from Friday for two weeks, back on the 14th April, so I won't be able to do much testing or maintenance. :( ;-)) Duncan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
