On 24.03.2009 09:22, Niedermeier Günter wrote:
Replaying TS produces "no" CPU load.
>>> Forget it! This seems to be fixed too since your patch.
>>>
>>> Could that be possible?
>> I don't think so. The modified code is not involved
>> in replaying, only in recording.
>
> However, currently 174
On 24.03.2009 17:05, Jouni Karvo wrote:
> Klaus Schmidinger kirjoitti:
>> On 23.03.2009 22:13, Klaus Schmidinger wrote:
>>
>>> On 23.03.2009 21:42, Niedermeier Günter wrote:
>>>
> Here's a quick shot - totally untested (no time, sorry).
> Please try it and let me know if it helps.
>
Klaus Schmidinger kirjoitti:
> On 23.03.2009 22:13, Klaus Schmidinger wrote:
>
>> On 23.03.2009 21:42, Niedermeier Günter wrote:
>>
Here's a quick shot - totally untested (no time, sorry).
Please try it and let me know if it helps.
>>> Hi,
>>>
>>> I've tried it:
>>>
>>> One question (OT): is it normal that replaying a PES record causes
>>> in a very high CPU load on 1.7.2 and higher? -> 80-90% on a P4/2400
>>>
>>> Replaying TS produces "no" CPU load.
>>
>> Forget it! This seems to be fixed too since your patch.
>>
>> Could that be possible?
>I don't think s
>>> Replaying TS produces "no" CPU load.
>> Forget it! This seems to be fixed too since your patch.
>>
>> Could that be possible?
>
> I don't think so. The modified code is not involved
> in replaying, only in recording.
However, currently 174 works without high CPU load in my
environment. I had
On 03/24/09 01:09, Niedermeier Günter wrote:
>> One question (OT): is it normal that replaying a PES record causes
>> in a very high CPU load on 1.7.2 and higher? -> 80-90% on a P4/2400
>>
>> Replaying TS produces "no" CPU load.
>
> Forget it! This seems to be fixed too since your patch.
>
> Coul
> One question (OT): is it normal that replaying a PES record causes
> in a very high CPU load on 1.7.2 and higher? -> 80-90% on a P4/2400
>
> Replaying TS produces "no" CPU load.
Forget it! This seems to be fixed too since your patch.
Could that be possible?
-Günter
--
This message was scanne
> Just another quick thing to test: please add
>
> }
> Data += TS_SIZE; <== this line
> Length -= TS_SIZE;
> Processed += TS_SIZE;
> }
> return Processed;
> }
>
> to the end of cFrameDetector::Analyze().
...looks good at all!
I've tested streaming of f
On 23.03.2009 22:13, Klaus Schmidinger wrote:
> On 23.03.2009 21:42, Niedermeier Günter wrote:
>>> Here's a quick shot - totally untested (no time, sorry).
>>> Please try it and let me know if it helps.
>> Hi,
>>
>> I've tried it:
>> files are created, but with zero filesize.
>> Only info is correc
On 23.03.2009 21:42, Niedermeier Günter wrote:
>> Here's a quick shot - totally untested (no time, sorry).
>> Please try it and let me know if it helps.
>
> Hi,
>
> I've tried it:
> files are created, but with zero filesize.
> Only info is correct.
>
> After a few seconds vdr is restarting with
> Here's a quick shot - totally untested (no time, sorry).
> Please try it and let me know if it helps.
Hi,
I've tried it:
files are created, but with zero filesize.
Only info is correct.
After a few seconds vdr is restarting with an "emergency exit!".
-Günter
--
This message was scanned by ES
On 23.03.2009 08:35, Klaus Schmidinger wrote:
> On 23.03.2009 01:09, Niedermeier Günter wrote:
>>> There must be an other problem that's causing this, but since this doesn't
>>> happen here on my system, I'm afraid you'll need to do the debugging ;-)
>> Which changes have been made between 1.7.2 an
On 23.03.2009 01:46, Hawes, Mark wrote:
>>> A TS recording is only marginally more data than the same length recording
>>> in PES. I don't think that recording in TS should require so much more
>>> bandwidth
>>> than PES.
>
>> That's clear to me.
>
>>> There must be an other problem that's causi
On 23.03.2009 01:09, Niedermeier Günter wrote:
>> There must be an other problem that's causing this, but since this doesn't
>> happen here on my system, I'm afraid you'll need to do the debugging ;-)
>
> Which changes have been made between 1.7.2 and 1.7.3 in
> file writing mechanism?
>
> Not co
>> A TS recording is only marginally more data than the same length recording
>> in PES. I don't think that recording in TS should require so much more
>> bandwidth
>> than PES.
>That's clear to me.
>> There must be an other problem that's causing this, but since this doesn't
>> happen here on m
> There must be an other problem that's causing this, but since this doesn't
> happen here on my system, I'm afraid you'll need to do the debugging ;-)
Which changes have been made between 1.7.2 and 1.7.3 in
file writing mechanism?
Not codechanges, because I dont understand them, but in words ple
On 22.03.2009 19:06, Niedermeier Günter wrote:
> ...is there switch, or simple possibility to change recording
> format from TS to PES in 1.7.4 - just for a simple verification?
Sorry, PES recordign has been completely removed from VDR.
> In your environment, do you stream over net or local disk?
...is there switch, or simple possibility to change recording
format from TS to PES in 1.7.4 - just for a simple verification?
BTW:
In your environment, do you stream over net or local disk?
Because streaming to a local (linux)disk makes no problem,
and would be hard to produce it, or measure the
> A TS recording is only marginally more data than the same length recording
> in PES. I don't think that recording in TS should require so much more
> bandwidth
> than PES.
That's clear to me.
> There must be an other problem that's causing this, but since this doesn't
> happen here on my syste
On 22.03.2009 15:36, Niedermeier Günter wrote:
>> Well, if there are buffer overflows and the TS data is corrupted, it's
>> no wonder the index file stops growing.
>>
>> Does this happen on all channels, or only on some (or even only on a
>> particular one)?
>>
>
> Additional infos:
>
> I recompi
> Well, if there are buffer overflows and the TS data is corrupted, it's
> no wonder the index file stops growing.
>
> Does this happen on all channels, or only on some (or even only on a
> particular one)?
>
Additional infos:
I recompiled older versions beginning at 1.7.3 and made some tests.
>
> Well, if there are buffer overflows and the TS data is corrupted, it's
> no wonder the index file stops growing.
>
> Does this happen on all channels, or only on some (or even only on a
> particular one)?
Well, I've tried it on several channels
ARD,ZDF,arte,Das Vierte,MünchenTV and so on.
C
On 22.03.2009 12:39, Niedermeier Günter wrote:
>> Strange - the code for actually writing the index file hasn't changed
>> between PES and TS recording. But maybe you can take a closer look at
>> the changes to cIndexFile between version 1.7.2 and 1.7.3.
>
> Possibly you may want to have a look to
> Strange - the code for actually writing the index file hasn't changed
> between PES and TS recording. But maybe you can take a closer look at
> the changes to cIndexFile between version 1.7.2 and 1.7.3.
Possibly you may want to have a look to my logfile,
while the error occurs:
snip
Klaus Schmidinger wrote:
> I believe you mean 'genindex'.
> Maybe I should make VDR automatically generate an index file when replaying
> a TS recording without one...
good idea
stefan
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-b
>> I've never had a problem like this in older VDR versions, and I often do
>> cutting and recording at the same time.
>
> Strange - the code for actually writing the index file hasn't changed
> between PES and TS recording. But maybe you can take a closer look at
> the changes to cIndexFile betwe
On 22.03.2009 09:15, Hawes, Mark wrote:
>
>
> ...
> I have checked the recording directory and sure enough, the index file stops
> growing after a short while (seconds).
> I have tried mounting the NTFS partition with the async option but to no
> avail, i.e. problem is still there.
Please try
Hawes, Mark schrieb:
>
>
> /If I pause live video then restart it starts in slo-mo i.e. judders, and/
>
>>>/ then eventually freezes, but may then start again, still juddering …./
>
>>>/ and freezing …/
>
>>/ /
>
>>/ Well, then I have no idea why it wouldn't work with an NTFS partition,/
>
On 22.03.2009 01:42, Niedermeier Günter wrote:
>>> If I pause live video then restart it starts in slo-mo i.e. judders, and
>>> then eventually freezes, but may then start again, still juddering ….
>>> and freezing …
>> Well, then I have no idea why it wouldn't work with an NTFS partition,
>> while
>> If I pause live video then restart it starts in slo-mo i.e. judders, and
>> then eventually freezes, but may then start again, still juddering ….
>> and freezing …
>
> Well, then I have no idea why it wouldn't work with an NTFS partition,
> while it does work with others.
>
> Klaus
Hi Klaus,
On 21.03.2009 00:51, Hawes, Mark wrote:
> On 20.03.2009 13:11, Hawes, Mark wrote:
>
>
>
>>/ Since upgrading to VDR-1.7.4 I have experienced some instability when/
>
>>/ recording to an NTFS partition./
>
>>/ /
>
>>/ /
>
>>/ /
>
>>/ The recording itself seems to proceed OK, but the recorde
On 20.03.2009 13:11, Hawes, Mark wrote:
> Since upgrading to VDR-1.7.4 I have experienced some instability when
> recording to an NTFS partition.
>
>
>
> The recording itself seems to proceed OK, but the recorded programs
will
> generally only play for a few seconds before freezing. Pausing l
On 20.03.2009 13:11, Hawes, Mark wrote:
> Since upgrading to VDR-1.7.4 I have experienced some instability when
> recording to an NTFS partition.
>
>
>
> The recording itself seems to proceed OK, but the recorded programs will
> generally only play for a few seconds before freezing. Pausing li
33 matches
Mail list logo
