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-dev
el
|
