Posts by HolgerAusB

    Um nochmal auf das Problem zurück zu kommen wonach ein Abfragen der index.vdr bei Aufzeichnungen nicht überall zu funktionieren scheint.

    Ich vermute es liegt an den neueren vdr-Versionen, bei mir geht es unter 1.6.0 nämlich auch nicht.

    Ich hoffe folgende Abwandlung ist korrekt:

    Code
    lsof | egrep "[0-9]{3}\.vdr"

    Hier wird jetzt auf die Video-Dateien 001.vdr und folgende geprüft.

    Ist es eigentlich Absicht, dass ein "apt-get source vdr" die Version 1.7 lädt anstatt 1.6?

    Erst wenn ich die Versionsnummer anhänge klaptts:

    Hallo,

    ein dist-upgrade habe ich nicht gemacht, weil das auch einen anderen kernel eingespielt hätte. Stattdessen habe ich openssh-server/client und dieses blacklist-Paket per apt-get install geholt.

    Beim Installieren hat er gleich neue Hostkeys für ssh gereriert und ab da kam ich per Putty nicht mehr auf den vdr.

    Ich habe dann versucht die Schlüssel noch mal händisch zu erstellen, sowohl mit ssh-keygen als auch mit 'dpkg-reconfigure openssh-server', immer das gleiche Ergebnis.

    ein /etc/init.d/ssh restart beschwert sich, dass die beiden neuen Schlüssel blacklisted sind. und ssh-vulnkey markiert beide als COMPROMISED.

    Habe ich da doch irgendwo ne falsche Paket-Version geladen? Eigentlich dürfte der doch keine schwachen Keys mehr produzieren, oder?

    openssh-server und -client: 1:4.3p2-9etch2
    openssl: 0.9.8c-4etch3
    openssh-blacklist: 0.1.1

    das wäre aber ein standard-kernel gewesen und nicht der bigmem von backports.org, faktisch vermutlich sogar eine deaktualisierung.

    ich habs jetzt wie oben mit install gemacht und habe auch die blacklist nachgezogen.

    Dafür darf ich heute Abend noch rausfriemeln, wie ich mit putty wieder auf den vdr komme :(

    Du hast beim Update die Frage nach dem Überschreiben der config.pl offensichtlich verneint.

    Dir fehlt mindestens der irgendwann neu hinzugekommene Parameter

    Code
    our $tvmMax=14;

    Damit wird für jeden Dienst ein absolutes Maximum festgelegt. Es wird dann immer der niedrigste Wert aus $days2download oder <dienst>Max genommen.

    Suche mal in /etc/vdr/tvmovie2vdr nach eine config.pl mit einem Zusatz Dateinamen, weiß grad net wie der aussehen muss.

    So nun bin ich bei Version 0.0.6-beta3 und einem von tobi (hoffentlich) entsprechend gepatchten vdr-multipatch 1.6.0-1ctvdr8.

    Leider wird die noepg-List immer noch nach jedem noepgmenu-Plugin-Aufruf invertiert, außer ich gehe mit Exit aus dem Plugin :(

    Hallo Tobi, danke für das Update.

    Beim Start des VDR erhalte ich ein:

    Code
    WARNING: The following plugins have been left out due to possible binary incompatibility: noepgmenu.

    Das Plugin ist natürlich auch aktuell:

    Code
    vdr1:/# apt-cache policy vdr-plugin-noepgmenu
    vdr-plugin-noepgmenu:
      Installiert:0.0.6.beta2-1
      Mögliche Pakete:0.0.6.beta2-1
      Versions-Tabelle:
     *** 0.0.6.beta2-1 0
            100 /var/lib/dpkg/status
         0.0.6~beta3-1 0
            700 http://e-tobi.net etch/vdr-multipatch Packages

    wobei hier jetzt was von einer beta3 steht?

    EDIT:

    OK, irgendwie erkennt apt nicht, dass beta3 aktueller ist als beta2:

    Code
    vdr1:/# apt-get install vdr-plugin-noepgmenu=0.0.6~beta3-1
    Paketlisten werden gelesen... Fertig
    Abhängigkeitsbaum wird aufgebaut... Fertig
    Die folgenden Pakete werden DEAKTUALISIERT:
      vdr-plugin-noepgmenu

    Wenn ich die Rückfrage bestätige gehts.

    Ob es noch aktuell ist, kann ich erst am Donnerstag oder Freitag testen.

    Ein anderes Problem ist uns aber noch aufgefallen. Der erste mplayer Aufruf zum Ermitteln der Videogröße erfolgt ohne Parameter "-ao null -vo null", was bei ct zu Problemen führt, Details siehe hier in diesem Thread. Ich hatte das gelöst, indem ich den Pfad zu mplayer auf das Script des debian-vdr-mplayer-Plugins verbogen habe.

    Richtiger wäre aber das Script um die Parameter zu erweitern, oder?

    Allerdings hat das natürlich nichts mit dem Lastproblem zu tun.

    Wie ich oben schon schrieb, sind die Ruckler auch Senderabhängig.

    Quote

    Original von FrankJepsen


    Welches Verhalten ist denn für dich so störend und muss abschaltbar sein?


    Ich muss leider zugeben, dass ich mir den Editmarks-Patch bis gerade noch gar nicht angesehen habe. Ich hatte den bösen Verdacht das könnte etwas ähnlichs sein wie jener Patch, der unlängst bei vdrdevel-1.5 über dem liemikuutio "eingeschleust" wurde.

    Die Änderung dort bewirkte, dass nach skippen mit rot/grün bei Drücken der jeweils anderen Farbtaste innerhalb von 5 Sekunden die Schrittweite halbiert wird, also von 60, auf 30, 15 und minimal 7,5 Sekunden.

    Dieses Einkreisen mag hilfreich sein, wenn man tatsächlich Schnittmarken setzen will. Ich für meinen Teil nehme sehr viel auf und schaue dann manche Sachen aber nur im Schnelldurchlauf. Und hierzu brauche ich gleichbleibende Schrittweiten auch beim vor-zurück-vor-... hin-und-her-geskippe.

    Ich habe jetzt dann doch mal deinen Patch angesehen und war positiv überrascht, dass der das grün/rot-Verhalten gar nicht ändert, sondern eigentlich nur 1/3, was ich bislang auch zum Schneiden kaum verwendet habe. Pause nach Null ist sicher auch recht geil.

    Es wäre zumindest schön, wenn Tobi den Patch ins Source-Paket mit aufnimmt ohne ihn zu aktivieren.

    Quote

    Original von Tobi
    Den Editmarks-Patch möchte ich nicht mit in Multipatch aufnehmen, da er das Standardverhalten ändert, ohne das über eine Setup-Option an/abschalten zu können.

    Da kann ich dir nur dankend zustimmen! Als das (oder etwas ähnliches?) als Teil eine neuen liemikuutio-Version im vdrdevel-1.5 plötzlich auftauchte ohne Ankündigung, war ich ganz schön am schwitzen und habe an mir selbst gezweifelt, bis ich dann hier einen Beitrag dazu gelesen habe.

    Dieses Verhalten MUSS abschaltbar sein! Am liebsten auch umschaltbar per Tastendruck während der Wiedergabe, notfalls per keymacros.conf

    Ich hatte in einem anderen Thread [1] schon mal erwähnt, dass bei mir das Director-Plugin unter vdr 1.6.0 (e-tobi/experimental/multipatch) nicht funktioniert.

    Als "EDIT" hatte ich gleich darauf erwähnt, dass es nach Durchzappen aller Optionskanäle wieder gehen würde. Leider konnte ich diesen Effekt so nicht wiederholen. Am nächsten Tag hatte ich wieder kein Optionskanäle im Director und Durchzappen war erfolglos.

    Zwischenzeitlich vermute ich die Ursache in meiner Einstellung des noEPG-Patches der bei mir auf whitelist steht (standard=blacklist). Ich habe für meine Tests nach Umstellen der Optionen jeweils den vdr gestopt und die epg.data gelöscht.

    Wenn ich epg auf blacklist stelle funktioniert es und wenn ich im whitelistmodus den Portal-Kanal für EPG freischalte funktioniert es auch.

    Wenn ich aber im Whitlist-Modus den Portalkanal nicht in die Whitelist aufnehme, geht es leider nicht.

    Der Director braucht also offensichtlich die EPG-Daten um die verlinkten Channel zu ermitteln.

    Ist das nun tatsächlich technisch erforderlich oder ist das schon der zweite Fehler im noEPG-Patch nach diesem [2]?

    [1] [UPDATE vdr-experimental] vdr 1.6.0

    [2] noEPG mit ct-vdr-1.6.0

    Für die CO2-Bilanz macht das kaum einen Unterschied, nur wenn jetzt jemand eine Korrektur oder Ergänzung zu dem Patch machen wollte, müsste er dies in drei Threads tun um nicht Gefahr zu laufen, dass diese Änderung übersehen wird.

    Wenn du den Patch nur einmal gepostet hättest und in den anderen Threads einen Links gesetzt hättest redudiziert sich der Arbeitsaufwand ... und dadurch indirekt vermutlich auch der CO2-Ausstoß ;D