Posts by Nachteule

Wow, was für eine Diskussion.

Was mich betrifft wird da nix gestöpselt, es geht nur darum dass nach einer idle Zeit das device halt wieder freigegeben wird. Und das funzt auch mit dem Patch für 2.4.1 nach wie vor prima. Und meiner Meinung nach ist es längst überfällig dass sowas im vdr ootb funktionieren würde. TVHeadend hat sowas beispielsweise von Hause aus drinne

Ja, ich hab mir den diff auch schon gestern selber angepasst. Test steht aber noch aus. Und ja, der Patch hat sich leicht anpassen lassen

Es wunderte mich halt nur dass auf dem launchpad repo extra darauf hingewiesen wurde dass dieses Paket fehlt da es halt eben noch keinen angepassten Patch gibt

Wenns denn mal funktionieren sollte dann mach ich ggf auch mal einen PR

Hallo Leute, gibt's denn mittlerweile einen funktionierenden Patch für dynamite plugin? Der Winter ist ja schon lang rum

Quote from SHF

Die Nummer 2 war irgendwie vom alten Lockningsystem.
Wenn ich es richtig sehe ist es durch das Makro LOCK_TIMERS_WRITE ersetzt.

Das würde ich auch so sehen

Ich seh grad,

Timers.BeingEdited()

ist im Epgsearch Plugin auch nur deaktiviert worden

Quote from mini73

Das sind auch ungefähr die Stellen, an denen ich dann aufgegeben habe. Zumindest bei Nummer 3 muss man sich dort irgendwo einen StateKey merken, und mit diesem die Recordings überprüfen, ob sie sich seit dem letzten mal geändert haben. Wenn man immer "true" annimmt, wird live ständig was tun und unnötig CPU verbrennen.

Davon ging ich auch aus, aber wenn die Funktionen von dem Erleuchteten (sorry für den Sarkasmus) wegoptimiert wurden, dann geht das halt eben nicht. Bei meinem Kurztest gestern abend konnte ich aber keine permanente CPU Last erkennen. Ich vermute mal, dass das nur zum Tragen kommt wenn man auf der Web-Oberfläche herumklickt.

Quote from mini73

Ähnliches gilt für Timers.BeingEdited. Da muss man ggf. prüfen, ob jemand einen Write-Lock auf die Timer hat und dann entsprechend aussteigen.

Das bringt aber auch nix, da man ja nicht zwangsläufig jeden Write-Lock mitbekommt. Sollte aber auch egal sein, da ein LOCK_TIMERS_WRITE ja solange wartet bis eventuell bereits vorhandene Write Locks wieder entfernt wurden.

Quote from mini73

Und das "Modified" der Timer fragt man auch über einen StateKey ab, den man vorhalten muss.

Völlig richtig. Aber was nicht vorhanden ist lässt sich halt auch nicht verwenden. Tolle Weiterentwicklung kann ich da nur sagen

Quote from wirbel

Hat jemand schon vdr-live an 2.3.1 angepasst?

Ich würde es eigentlich gerne benutzen, aber alles was ich finde ist alt und
z.Z. scheitere ich an den extremen Änderungen zwischen vdr-2.2 und 2.3.1.

Einfach mal so nach Schema 'X' die Änderungen einzupflegen funktioniert bei diesem Plugin eher nicht,
und es wär schade Zeit zu verschwenden dafür, wenn jmd anders etwas fertig hat
Man kommt wegen tntnet, gleichzeitigem Zugriff auf EPG , Channels und Aufzeichnungen bei dem Plugin in Teufels Küche.

Ich hatte mich die letzten Tage mal daran gemacht, muss allerdings sagen dass ich von den Internas des VDR im Allgemeinen und von Live im Besonderen reichlich wenig verstehe. Wie dem auch sei, das Plugin lässt sich compilieren und läuft auch soweit ich das beurteilen kann. Ich verwende davon allerdings nicht viele Funktionen.

Drei Dinge haben sich leider nicht anpassen lassen, da die Methoden aus welchen Gründen auch immer nicht mehr vorhanden sind:

1. Timers: Timers->Modified gibt es nicht mehr, es wird halt immer true zurückgegeben

#if VDRVERSNUM >= 20301
                    	bool Modified() { return true; }
#else
                    	bool Modified() { return Timers.Modified(m_state); }
#endif

2. Timers: Timers->BeingEdited gibt es nicht mehr, diese Überprüfung finded halt nicht mehr statt

+#if VDRVERSNUM < 20301
            	if ( Timers.BeingEdited() ) {
                    	StoreError( timerData, tr("Timers are being edited - try again later") );
                    	return;
            	}
+#endif

3. Recordings: Recordings->StateChanged gibt es ebenfalls nicht mehr, es wird halt immer true angenommen

#if VDRVERSNUM >= 20301
            	bool stateChanged = true;
#else
            	bool stateChanged = Recordings.StateChanged(m_recordingsState);
#endif
            	if (stateChanged || (!m_recTree) || (!m_recList) || (!m_recDirs)) {

Bei meinen Tests mit maximal 3 Timern und 3 Recordings dürfte das sich nicht nachteilig auswirken, wie das allerdings ist wenn man viele Recordings hat kann ich nicht beurteilen, wenn ich mal 10 Aufnahmen habe dann ist das schon viel

Für Interessierte habe ich meinen Patch hier mit beigelegt.

Quote from hepi

Und die andere Quelle war nicht Channelpedia?

Nein, ich kann nicht mehr sagen von wo ich die her habe, aus irgendeinem Forum, aber woher genau kann ich nicht mehr sagen. Ist auch schon ne Weile her, mein Entscheidungsprozess, endlich den brachliegenden Kabelanschluss zu nutzen, hat etwas länger gedauert. Mit entscheidend was dass die Grundverschlüsselung für RTL & Co nun Anfang April abgeschafft wird und sich RTL irgendwann wohl mal aus dem DVB-T Netz zurückzieht (traurig traurig)

Die Channelpedia (Super Sache !!!) hab ich erst jetzt gefunden

Quote from gda

Die Sticks von Sundtek gehen immer, egal welcher Kernel

Ja, das ist mir bekannt. Ist ja einer der wenigen die offiziell richtig unterstützt werden.
Geht bei diesen Sticks denn s2ram und s2disk fehlerfrei ohne herum zu tricksen?

Das Problem habe ich übrigens jetzt gelöst. Die Ursache lag in einer inkorrekten channels.conf.
scan (w_scan ging aus unerfindlichen Gründen gar nicht) hat für jeden Kanal als Streamtyp eine 2 (MPEG2) eingetragen, wobei korrekterweise eine 27 für H264 codierte HD Kanäle stehen muss. Kein Wunder, dass dann nichts aufgezeichnet werden konnte. Das VNSI Plugin ist da wohl etwas intelligenter ?? und macht die Erkennung irgendwie anders. Darum ging der LiveTV in XBMC stets einwandfrei. Unglücklicherweise hatte ich mir von anderer Quelle eine fertige channels.conf zu Referenzzwecke heruntergeladen, da stand es bei den HD-Kanälen 2x richtig drinnen und 1x falsch. Und ich habe es natürlich immer mit dem falschen Eintrag verglichen.

Jetzt läuft alles prima. Danke nochmal für's Mitdenken

Gruß Manfred

Quote from Activyst2010

ich wusste garnicht, dass der Cinergy HTC USB XS HD überhaupt unter Linux, bzw. vdr läuft. Die Übersicht im VDR-Wiki sagt nämlich immer noch, besagter Stick würde unter vdr nicht unterstützt, bzw. umgekehrt.

Ja, das ist halt immer so eine Sache mit der Unterstützung der Hardware unter Linux. Bevor ich mich zum Kauf dieses Sticks entschlossen hatte, habe ich natürlich etliches recherchiert bezüglich der Linux Unterstützung von DVB-C Hardware, speziell USB Sticks. USB sollte es sein, da ich halt nur einen PCI-E Slot habe und der derzeit halt schon anderweitig belegt ist. Zu Rate gezogen habe ich die Linux Seite von Terratec und die Kernel-Quellen. Terratec gibt ja die VID's und PID's ihrer Sticks preis und anhand dieser Information konnte ich sehen, dass aktuelle Kernel damit bereits etwas anfangen können. Und dann gibts natürlich noch die Datei CARDLIST.em28xx in den Kernel Quellen, da steht dieser Stick halt auch drinnen

Das System wird natürlich nicht neu gebootet.

Es beendet sich halt der vdr und über das runvdr Skript wird der vdr halt einfach neu gestartet.

Und da in der /etc/vdr/timers.conf der Timer noch drinnen steht, wird er halt gleich wieder aktiviert. Das geht solange bis ich den Timer halt wieder manuell entferne.

Gruß Manfred

Der DVB-C Stick ist direkt über ein 3m langes Kabel an der Antennendose ohne T-Stück angeschlossen. An dieser Dose hängt zusätzlich nur das Kabelmodem, habe hier Internet via Kabel(Deutschland).

Über die Signalqualität kann ich leider nur spekulieren, da der Linux-Kernel in den neuen Versionen irgendwie fehlerhaft ist (da wurde einiges umgemodelt) und ich als SNR und Signalstärke sowohl bei DVB-T als auch bei DVB-C immer 0 angezeigt bekomme.

Gucke ich LiveTV im XBMC, so kann ich keine Störungen erkennen, sowohl bei den SD als auch bei den HD Kanälen, auch habe ich mal versuchsweise ein richtig langes Kabel vewendet, machte keinen Unterschied. Würde also vermuten dass das Signal in Ordnung ist.

Hallo,

ich betreibe hier einen HTPC unter openSUSE 12.2 64Bit mit VDR 1.7.27 bzw. testweise jetzt auch 1.7.40 (ohne jegliche Patches) mit jeweils einem DVB-T und einem DVB-C USB Stick als Backend und XBMC / VNSI Plugin als Frontend.
Als DVB-T Stick kommt ein Terratec Cinergy USB XS (seit über einem Jahr) und als DVB-C ein Terratec Cinergy HTC USB XS HD (seit letzter Woche) zum Einsatz.

Der DVB-C Stick kam erst letzte Woche hinzu und damit begann mein Problem.
Anfangs ging das mit dem DVB-C wirklich einwandfrei, angesteckt, wurde gleich erkannt, Kanalscan gemacht, alle Kanäle da, und gucken ging im XBMC sofort, incl. den FTA HD Kanälen (Das Erste HD, ZDF HD und Arte HD). Erfahrungsgemäß ist das immer verdächtig wenn etwas gleich funktioniert, so wie jetzt auch

Jetzt wollte ich gestern mal eine HD-Aufnahme machen und dann gings los mit der Meldung

Mar 11 16:24:11 [9472] ERROR: video data stream broken
Mar 11 16:24:11 [9472] initiating emergency exit
Mar 11 16:24:11 [9389] emergency exit requested - shutting down

und das natürlich am laufenden Band, da er nach dem Neustart immer wieder den Timer startet.

Nun hab ich über das VDSB Problem schon einiges gelesen, würde aber mal sagen das trifft bei mir alles nicht zu, da er schon gar nicht anfängt irgendetwas aufzuzeichen (das .ts File hat immer die Länge 0)
Ich hab heute mal in den Quellen gestöbert und ein paar Testausschriften eingebaut, das Problem hier ist dass er sich gar nicht sich auf den Datenstrom synchronisieren kann. Pakete kommen jede Menge an, aber da er mit keinem etwas anfangen kann, bricht er halt nach 30s mit obiger Meldung ab.

Testweise hab ich auch mal mit Kaffeine geschaut, ob der mit den HD Kanälen was anfangen kann, das klappt einwandfrei.

Auch das Entfernen des DVB-T Sticks und das Ausdünnen der channels.conf brachte keinen Erfolg.

Ich bin da jetzt natürlich völlig ratlos was die Ursache betrifft, hoffentlich kann mir da jemand helfen

lg Manfred