moin,
nachdem ich hier pvr server ohne dvb device - möglich? mein problem geschildert habe bin ich dem schuldigen jetzt auf die schliche gekommen - es ist pvrinput. sobald ich das plugin weglasse konsumiert vdr seine übliche ~1% der cpu. mit aktiviertem pvrinput die erwähnten 20-30%..
debian lenny 2.6.28.2 (standard debian kernel)
ivtv (utils) 1.3.0
pvrinput 2008-10-04
vdr 1.6
jemand ne idee? dr. seltsam? 
infinite
so eine CPU-Last kenne ich aus alten Tagen, wo ich die PVR mit dem analogtv-Plugin und CPUs unter 600 MHz betrieben habe. Mit P3 1GHZ und pvrinput habe ich nur wenige Prozent CPU-Last.
Ein paar Prozent sind normal, das kommt von der live-Umwandlung des PES Streams in TS.
Wird es weniger, wenn Du im pvrinput-setup sliced VBI ausschaltest?
setz mal
pvrinput.SliceVBI = 0
glaube aber nicht, dass es einen Unterschied ausmacht. Interessant wäre, ob diese CPU-Last auch entsteht, wenn Dein Ausgabedevice von einem anderen device (DVB) seine Daten bekommt.
Oder lass doch vdr mal ohne xineliboutput laufen, nur mit dummydevice und pvrinput.
Dass die CPU-Last erst mit pvrinput steigt, würde ich darauf zurückführen, dass ohne die Daten eines Eingabedevices ja auch nichts zu tun ist.
funktioniert denn der Empfang?
starte vdr doch mal auf der Konsole, damit man die debug-Meldungen von pvrinput sieht
Moin!
Mein Sempron LE-1200 (per powernowd läuft der mit 1GHz) hat eine Auslastung von 5% während eine Aufnahme läuft. Welcher Thread lastet dein System denn aus? Einfach mal mit top nachsehen und dann im Log die PID suchen, welcher Thread das ist. Vielleicht hilft das bei der Analyse.
mini.
Moin!
Ok, es ist also nicht irgendein Transfer-, Reader- oder Writer-Thread, der später gestartet wird? Hm, ich meine mich zu erinnern, dass ich mit dem dummydevice auch mal eine hohe Systemauslastung hatte. Schon schade, dass der vdr nicht ohne ein Ausgabegerät starten will (wirklich nicht? warum nicht? was macht man dann mit reinen Aufnahme-Servern?). Wie sieht's denn mit xinelibout, softdevice o.ä. aus? Diese Dinger hab ich aber noch nie benutzt, da weiß ich also noch weniger zu...
mini.
ZitatOriginal von mini73
Schon schade, dass der vdr nicht ohne ein Ausgabegerät starten will (wirklich nicht? warum nicht? was macht man dann mit reinen Aufnahme-Servern?).
doch, das geht - aber es muss mindestens ein DVB-(Eingabe)gerät gefunden werden. Wenn das einzige device ein pvrinput device ist, startet vdr nicht. Liegt glaube ich an dvbdevice.c
Ich glaube, dummydevice heilt das.
@ infinite:
welche Last hat vdr, wenn nur dummydevice und pvrinput als einzige Plugins gestartet werden, und vdr auf einen analogen Kanal geschaltet wird?
das ist mir unerklärlich. Du bist der erste, der so ein Problem berichtet.
Kommen denn besondere debug-Ausgaben vom pvrinput-Plugin? (siehst Du nur, wenn vdr auf der Konsole gestartet wird).
Falls irgendwas endlos geloggt würde wäre das evtl. eine Erklärung. Ändert sich was, wenn Du den loglevel im pvrinput-Plugin auf 0 stellst?
debug ausgaben sind wie oben gepostet.. log ändert sich erst dann sobald ich umschalte (logischerweise).
loglevel 0 hat auch nix gebracht.
sehr schade 
vielleicht kannst Du die Karte bei Gelegenheit mal mit einer anderen Distri und/oder Hardware testen.
Du könntest sonst auch mal testweise alle Aufrufe von
readThread = new cPvrReadThread(v4l2_fd, tsBuffer, &mutex, this);
in device.c auskommentieren. Dann kommt natürlich kein Bild, weil vom device nicht gelesen wird. Wenn die Last dann immer noch da wäre, wüsste man zumindest dass es nicht am read Thread liegt.
Moin!
Gerade lief mal keine Aufnahme, da konnte ich ein bisschen testen.
Wenn ich nur pvrinput und dummydevice laufen lasse, lastet der Transfer-Thread meine CPU zu 80% aus und ich kriege ständig Meldungen "buffer usage 70%...80%...90%" und "clearing transfer buffer..." und danach dann natürlich "TS continuity error".
Für mich sieht das so aus, als ob pvrinput und dummydevice irgendwie nicht miteinander können. Wo das jetzt aber genau hakt, ist schwer zu sagen, denn das dummydevice tut echt nicht viel.
Ich wühl mal auf gut Glück durch den vdr-Source, um mal zu verstehen, was da überhaupt passiert, aber viel Zeit habe ich heute nicht mehr. Und dass ich was verstehe, kann ich auch nicht versprechen. 
Eine spontane Idee: Da das dummydevice sich so schnell von "PlayVideo" zurück meldet, könnte es sein, dass da pvrinput irgendwie aus dem Tritt kommt? Dass da vielleicht irgendwo zu schnell nacheinander gepollt wird? Wie lang müsste das PlayVideo zögern (mit sleep), damit es sich "echter" benimmt?
mini.
interessant wäre, ob das gleiche auch auftritt, wenn Du dummydevice weg lässt und stattdessen eine DVB-Karte dazusteckst. vdr erklärt dann das DVB device zum primary device, auch wenn dies nichts ausgeben kann.
Die Poll-Funktion sieht ganz normal aus.
class cDummyDevice : cDevice {
public:
cDummyDevice() : cDevice() {}
virtual ~cDummyDevice() {}
virtual bool HasDecoder(void) const { return true; }
virtual bool SetPlayMode(ePlayMode PlayMode) {return true;}
virtual int PlayVideo(const uchar *Data, int Length) {return Length;}
#if VDRVERSNUM < 10318
virtual void PlayAudio(const uchar *Data, int Length) {return Length;}
#elif VDRVERSNUM < 10342
virtual int PlayAudio(const uchar *Data, int Length) {return Length;}
#else
virtual int PlayAudio(const uchar *Data, int Length, uchar Id) {return Length;}
#endif
virtual bool Poll(cPoller &Poller, int TimeoutMs = 0) {return true;}
virtual bool Flush(int TimeoutMs = 0) {return true;}
bool Start(void) {return true;}
};buffermeldungen / errors hab ich keine. leider hab ich erst vor kurzem meinen fundus an übrigen dvb karten verschachert, murphy lässt grüssen
mal sehen was ich da auftreiben kann.
edit:
ich glaube ned dass es an dummydevice liegt.
mit sämtlichen anderen plugins die ein ausgabedevice simulieren (pvr350, xineliboutput, ffnetdev) erhalte ich auch die 20-30% last. da liegt der hund meiner meinung nach ned begraben.
Moin!
Ich hab hier zwar noch irgendwo eine DVB-T-Karte rumliegen, aber das Basteln an meinem vdr ist immer etwas aufwendiger, da ich das Ding immer erst aus dem TV-Schrank "operieren" muss. Und dazu brauche ich dann etwas mehr Zeit, in der keine Aufnahmen usw. anstehen.
Wochenende sieht schlecht aus, nächste Woche könnte es vielleicht gehen.
mini.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!