Was there anything in the log when vdr-sxfe was started / stopped ?
I can not say, because I forgot to/didn't look at any log.
I'll give it a try with the new suspendoutput plugin.
Thank you
-Wanninger
---
--
This message was scanned by ESVA and is believed to be clean.
:14:29PM +0100, Niedermeier Günter wrote:
I use these config parameters for xineliboutput plugin
--local=none
--primary
--remote=0.0.0.0:37890
Yup, me too. In this case xineliboutput will be the primary display, and there
will always be a channel running on it. Which is the root cause of my
Hi,
I'm in the same situation, and most of my friends, using vdr the same way, too.
The only software, I currently know which works similar, is VOMP client/server.
It is also independant and could be run standalone on Linux and Windows.
But it is IMHO only a worst-case-replacement for sxfe.
I
Am 14.04.2015 um 09:56 schrieb Gerald Dachs:
Am 2015-04-14 08:59, schrieb Matthias Wächter:
While streamdev and VNSI/XVDR solve some of the issues, most notably
the multi-client dependency, they create new ones. No native OSD with
VNSI/XVDR, VDR configuration synchronization hassle with
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 no chance to
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 ESVA
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 four
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 scanned by
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,/
/ while it does
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 between
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:
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.
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.
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 system,
...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
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
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,
I have
17 matches
Mail list logo
