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.
___
Recent xineliboutput can trigger suspendoutput automatically when vdr-
sxfe is disconnected (this could use some testing ...). See --auto-
suspend option.
Is it enough to replace the xineliboutput plugin with the latest git-version
and start the plugin it with "-s" parameter, or must I do furth
at 03: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
Hi,
I use these config parameters for xineliboutput plugin
--local=none
--primary
--remote=0.0.0.0:37890
in MLD 5.1.
I have no local OSD because of using VDR as server, and I can use it on my
Ubuntus
as a remote display/client using vdr-sxfe...
-Wanninger
---
Am 21.12.2016 um 14:42 schrieb
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 streamde
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
>>> 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
> 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
> 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
> 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
...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
> 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
> 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
>> 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
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,/
>
>> 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,
19 matches
Mail list logo
