Posts by BeetleJuice

    Oh, please don´t missunderstand my post. I´m much more thankful for this fabulous distro as my posting will show. If I´m coming up thankless then please excuse me, I´m far from good in writing in english.


    I´m using yaVDR since 0.1.0 and I agreed with all the changes they made in the past. This is the first one who brings me in trouble, as my disk contains hundreds of files which have a resume file but didn´t was seen until now. Maybe this is a disadvantage only to me, in this case we would say "Einzeschicksal".


    I´m willing to do something to get this feature back but my problem is missing some ideas and mainly the needed knowledge. :-(

    I wnat to come back to this discussion as I do not see a real solution (which is helpful for normal users) on time.


    I agree with all your arguments from the developers view. But from my perspective the old behavior is a fantastic "feature". I or any other member of my family can have a short look into the recording to decide if it´s worth to keep, cut or view it. If already cutted, I have the possibility to have a look, decide to look it another time and make it become new (or unseen). It´s easy to use (my daughter is using that since she´s 5 years old) and very helpful.


    The "solid solution" fnu talked about did have three disadvantages comparing to the old behavior:


    • I don´t know how to works on my existing files (delete all the resume-files from my video-folder as in the passt few years I collected a big amount of recordings)


    • The solution didn´t works within extrecmenu (if I understand)


    • The solution isn´t very comfortabe as it needs many steps (changing recordings menu to the original one, select recording, press info, go down to delete resume mark, press OK and confirm with OK)


    I believe this is a much more complicated use and bigger loss of comfort as to view the last 10 seconds from a always viewed recording. Further on I think my daughter don´t do this as it is to much effort (greetings from puberty).


    So, from my point of view this unwanted behavior is a wonderful and worthy feature within VDR.


    So, all of theese are my personal meanings and problems but I bet there are many ohter users who wants to agree with (I hope so).


    If anyone has a users compatible solution to keep this feature, I would kiss his feets...

    Vom patch bearbeiten und Pakete neu basteln wollte ich mangels Erfahrung gerne die Finger weglassen. Eine Suche hier im Forum hat mich zumindest auch nicht schlauer gemacht (was sicher einfach gewesen wäre... :-)).


    Ist denn die Wahrscheinlichkeit gegeben das das alte Verhalten im yaVDR wieder einzug hält?

    Im Grunde habe ich es so gemacht wie es der erste Link von Seahawk hergibt. Ziel des ganzen war es, alle Grundfunktionen zum bedienen des VDR möglichst dicht beieinander zu haben. Deswegen habe ich die Farbtasten auf den Nummernblock gebracht. Die Pfeiltasten waren ja ohnehin schon "greifbar". Mit ein wenig Übung kann man den VDR komplett bedienen ohne auf die Tastatur schauen zu müssen. "Menü" habe ich zusätzlich auf die STRG-Taste gelegt, da man da gut mit dem Daumen rankommt, wenn man die rechte Hand auf dem Nummernblock liegen hat.


    Anbei die Änderungen in Bezug auf das yaVDR Standard-Layout:


    Tasten "m" und "p" von Ihren Funktionen (Befehle) befreit und somit zum schreiben von Text verfügbar gemacht
    Tasten "F5" bis "F9" für Funktionen "user5" bis "user9" eingetragen. Hierdurch geht die ursprüngliche Funktion von "F5" / "F6" für "Rücklauf" / "Vorlauf" verloren (geht ja noch über die Richtungstasten)
    Tasten "Bild hoch" / "Bild runter" für Funktion "Channel+" / "Channel-" eingetragen
    Taste "STRG" für Funktion "Menü"
    Taste "Space" für Funktion "0", da man beim Umbenennen gerne mal Space für ein Leerzeichen verwendet und die ursprünglich Funktion "OK" dann stört.
    Die oberen vier Tasten des Nummernblock (Num, /, * und -) für Funktionen rot, grün, gelb und blau.
    Da die Benutzung der Taste "Num" den Nummernblock jedesmal in der Betriebsart umschaltet, musste ich die Funktionen "0" bis "9" des VDR auf beide Betriebarten legen.
    Taste "+" vom Ziffernblock für Funktion "Menü"
    Taste "Enter" vom Ziffernblock für Funktion "OK"
    Taste "Entf / Del" vom Ziffernblock für Funktion "zurück"


    Keine Lösung habe ich bisher für die Eingabe von Sonder- und Satzzeichen beim Umbenennen von Aufnahmen, da der VDR hierfür keine Befehle kennt (zumindest kenn ich sie nicht).


    Als Datei habe ich ein JPG mit einem Tastaturbild und den Funktionszuordnungen und das Template "50_keys" für die remote.conf angehängt.


    Verbesserungsvorschläge sind auf jeden Fall erwünscht!


    Gruß,


    Andreas

    Hallo Keine_Ahnung,


    danke für das zurechtschubsen. Ich bin an der falschen Seite in den Wald gegangen und habe dort nur falsche Bäume gesehen. Mein altes Template für die XKeySym-Einträge der remote.conf funktioniert prima, das hatte ich überhaupt nicht ausprobiert. Ich war davon ausgegangen das dieses nur bei xineliboutput greift.


    Hallo gda,


    der von Dir genannten moralischen Verpflichtung würde ich ja auch gerne nachkommen. Dafür hättet Ihr aber schlampiger arbeiten müssen um mir eine reelle Chance zu geben einen Bug zu finden. :-)


    Das ich das "beta" unterschlagen habe, lag wohl daran das ich davon ausgehe das hier jeder um den Status weiß und man das nicht expliziet erwähnen muss. Das war kein Irrglaube und auch keine böse Absicht.


    Nimm es doch einfach als Kompliment an Eurer Arbeit, dass ich einen Client und einen Server in Betrieb nehme und nach drei Tagen nichts anderes zu tun habe als eine Lösung für ein Komfort-Feature zu suchen.


    Wenn es Eurer Philosophie nicht wiederspricht, dann würde ich das Thema als gelöst kennzeichnen, mein Template für die remote.conf und eine Übersichtsgrafik der Tastenfunktionen anhängen. Das wäre dann aber ein Feature, kein Bug.


    Gruß,


    Andreas

    Unter yaVDR bis Version 0.4.0 habe ich vdr-plugin-xineliboutput benutzt und mir zum Schneiden und Umbenennen das Tastaturlayout angepasst. Massgeblich ging es darum alle Buchstaben (auch M und P) für das Umbenennen von Aufzeichnungsnamen und den Nummernblock zum schnelleren Schneiden nutzen zu können. Das ergibt beim schneiden einen durchaus höheren Komfort, was sich gerade beim Abarbeiten mehrerer Aufnahmen bemerkbar macht. Dies wollte ich nun gerne auch für die Konfiguration mit softhddevice machen und benötige dazu kurz Unterstützung.


    Ich wollte hierfür ein Template erstellen, welches den Teil der remote.conf für die Funktionszuweisungen zu den Tastatur-Tasten ersetzt. Allerdings habe ich die Doku und das Forum hoch und runter gesucht aber keine Möglichkeit gefunden den Code von einzelnen Tasten zu ermitteln (z.B. KBD.Up = 00000000001B5B41). Diese würd ich aber benötigen, um z.B. den Aufruf von "Menü" auf die Windows-Taste zu legen und somit die Taste "M" frei zu bekommen.


    irw und evtest liefern keine in dem (aus meiner Sicht) passenden Format zurück und weder in den evmaps oder im großen weiten Web kann ich mehr finden, als ohnehin schon in der remote.con steht. Wie komme ich an die passenden Codes, damit ich die remote.conf erweitern kann? Ich benötige massgeblich die Codes für den Ziffernblock im Ziffern- und Navigationsmodus.


    Danke im Voraus,


    Andreas

    In vorauseilendem Gehorsam sag ich schon mal DANKE !!!!


    Vorauseilend deswegen, weil ich gerade nicht weiß welche Version ich aktuell habe... liest sich schon ganz schön bekoppt.


    Also ich habe am Montag Abend die 0.5.0 alpha installiert (und ich könnt schwören ich hab vorher im DL-Bereich geguckt ob´s was neues gibt. Wie auch immer. Nach der Installation habe ich ein dist-upgrade gemacht ohne mir bewusst zu sein das ich dadurch auf die beta umsteige.


    Kann ich das denn jetzt an irgend einer Stelle prüfen ob ich noch auf alpha oder schon auf beta bin?


    Kernel und VDR-Version sind doch bei beiden im aktuellsten Stand die gleichen, oder?


    LG,


    Beetle

    Und wie stellt Ihr jetzt das EPG-Update sicher? Manuell ausführen ist ja sicher auch nicht der wahre Jakob oder gibt es noch andere Möglichkeiten?


    By the way: Funktioniert das CAM mit einer TT S-3200 ink. zughörigem CI out of the box oder gibt es evtl. ein howto (Sky mit Alphacrypt)? Die Suche im Forum hat mich hierher geführt, was besseres habe ichleider nicht gefunden. Ich stehe kurz vor Bestellung der Karte und wäre um einen kleinen Hinweis sehr dankbar.


    Many THX,


    Andreas

    Hallo Seahawk, Dein letzter Satz hat mein "Problem" gelöst. MIt dem Template mache ich es schon eine Weile aber Eure Warnung hat mich nach einer Lösung für ein inexistentes Problem suchen lassen. In den vorangegangenen yaVDR-Versionen habe ich zu oft an Eurer Struktur vorbei-gepfuscht. Das wollte ich jetzt mal ganz anders machen und habe mich dabei wohl verannt.


    Danke !

    Über das Thema "die Fernbedienung für den yaVDR zu ändern" habe ich nun schon so einiges gelesen. Allerdings möchte ich eigentlich die Tastaturbelegung ändern. In den vorangegangenen yaVDR-Versionen habe ich das in der remote.conf getan.


    Ziel der Änderungen:


    Um mit einer "normalen Tastaur" effektiv Aufnahmen schneiden, umbenennen und verschieben zu können, habe ich z.B. den Aufruf des Menü von der Taste "M" auf die Windows-Taste umgelegt. Somit steht "m" wieder zum umbennen im extrecmenu zur Verfügung. Auf den Ziffernblock habe ich die Ziffern selber, die Farbtasten, Menü und Zurück gelegt. Damit kann man dann sehr effizient die Schnittmarken bearbeiten. :D


    Kleiner Umstand / Nachteil: Da ich die oberen vier Tasten als Farbtasten benutze, musste ich den Ziffernblock in beiden Betriebsarten belegen, da die Benutzung von "rot" (Num Lock) natürlich jedesmal den Ziffernblock umschaltet.


    Anbei meine Einträge in der remote.conf, welche das eventuell verdeutlichen:



    Mit dem neuen Konstrukt unter eventlirc fuktioniert dieses nicht mehr. Ich bin bisher nicht dahinter gekommen, wie und wo ich eine evmap für die normale Tastatur erzeuge. :wand


    Bitte führt mich auf den Weg der Erleuchtung.

    Ich möchte diesen alten Thread nochmal ergänzen, da ich glaube das mein "Problem" hier gut reinpasst.


    Ich habe bei mir einen yaVDR basierten Server (0.3.0a), einen yaVDR Client (0.3.0a), einen MacMini (OSX 10.6), einen WinXP und einen Win7 Rechner. Auf dem yaVDR Server läuft Samba und NFS als Server. Alles ist über Gig-Ethernet verbunden. Die Performance beim Kopieren von und zu dem Server sind wie folgt:


    WinXP: 35 - 50 mb/s
    Win7: 55 - 85 mb/s
    OSX: 70 - 95 mb/s
    yaVDR nfs: 25 - 55 mb/s
    yaVDR smb: 15 - 18 mb/s


    Der IP-Stack oder die CIFS-Implementation von Win7 scheint also erheblich besser zu sein als bei XP. OSX scheint mir eher durch die Leistung der Platte begrenzt zu sein, ist aber nur eine Vermutung.


    Was mich stutzig macht, sind die Transferleistungen zwischen yaVDR Client und yaVDR Server. Gerade hier hätte ich die beste Performance erwartet, da hier auch die schnellsten Platten verbaut sind. Mangelnde Prozessorleistung schliesse ich auch aus, da der Client die schnellere CPU hat als der Server.


    Aber gerade dort benötige ich die Performance, da die Aufnahmen auf dem Server im Keller gemacht werden und ich diese auf dem Client schneide.


    Meine smb.conf auf dem Server:


    [global]
    workgroup = HomeOffice
    security = user
    announce as = NT Server
    announce version = 2000
    server string = vdr-server
    hosts allow = 192.168.1.0/255.255.255.0
    interfaces = 192.168.1.0/255.255.255.0
    bind interfaces only = yes


    log file = /var/log/samba/log.%m
    log level = 0
    max log size = 1000
    syslog = 0


    dns proxy = no
    guest account = nobody
    keep alive = 30
    os level = 2
    kernel oplocks = false
    encrypt passwords = true
    ssl = yes
    time server = true
    socket options = TCP_NODELAY IPTOS_LOWDELAY
    map to guest = bad user
    wins support = no
    os level = 33
    browse list = yes
    unix charset = ISO8859-15
    dos charset = CP850
    load printers = 0
    [data]
    netbios name = vdr-server
    netbios aliases = vdr-server
    comment = data
    path = /mnt/srv.data
    guest ok = yes
    writable = yes
    browseable = yes
    follow symlinks = yes
    preserve case = yes
    directory mode = 0775
    create mode = 0664
    force user = vdr
    force group = vdr


    Die fstab auf dem Client:


    //192.168.1.10/data /mnt/smb.data smbfs user,rw,noauto,username=user,password=pwd 0 0
    192.168.1.10:/mnt/srv.data /mnt/nfs.data nfs rw,hard,intr 0 0


    Hat jemand eine idee?


    Danke im voraus,


    Andreas

    Hallo Leute,


    ich sehe gerade in der aktuellen ct (2/2010) auf Seite 181 die Werbung für eine neue ct-Spezial mit dem Thema "Home Entertainment". Abgebildet ist eine beiliegende CD mit einer "Spezialversion ct-VDR".


    Auf dem heise-Kisosk (https://www.heise.de/kiosk/special/ct/09/08/) ist die Rede von "Für die Medienverteilung empfehlen wir unsere aktualisierte c't-VDR-Distribution, jetzt auch mit HD."


    Gefunden habe ich über die Suche nichts. Hat jemand einen Schimmer ob es hier um eine neuere Version als ctVDR 7.0 geht? Schliesslich gab´s ja schonmal eine Version ausschliesslich in einem Spezial... :schiel


    Gruß,


    BeetleJuice

    Kann man denn eine handelsübliche FB mit dem eingebauten IR-Empfänger anlernen und funktioniert dann auch das Einschalten via FB noch? Ich meine z.B. die FB der dbox, welche genau die (und nur die) benötigten Tasten für VDR mitbringt.

    Ich habe es mal mit meinem Server (ct´VDR 6.2) verifiziert. Dort laufen die Vicon-Fonts auch, allerdings zeigen sich dort immernoch die Fragezeichen als Platzhalter bei den 1 und 2stelligen Zahlen. Da werde ich mich allerdings nicht mehr auf die Suche machen denn der Server kommt am Wochenende auch mit der 7er Version dran.


    Bei meiner Activy habe ich es wie oben beschrieben hinbekommen. Ein Verzeichnis /usr/share/fonts/truetype/ttf-vicon erzeugt, die vier Dateien aus der o.g. Datei "skinenigmang-fonts-20080225.tgz" direkt (ohne weitere Unterverzeichnisse) hinein kopiert.


    Danach war der Font in den OSD-Einstellungen als Vicon:Bold oder Vicon:Roman auswählbar. Das war´s...

    jaja, ich glaub wir reden vom gleichen. Hab mich nur net besonders gut ausgedrückt. Plugin ist geladen und in den Settings des Plugin ist das LCD auch als vorhanden und somit als "an" eingestellt. War das erste mal das es im Plugin als Voreinstellung drin war, die letzten male musste ich es immer erst "einschalten".


    Die FB geht ohne mein händisches Workaraound aber immer noch nicht. Irgendwo scheint also das Plugin oder meine Installation noch ´ne Macke zu haben. Da stürz ich mich mal auf´s Google wenn ich mit dem Rest fertig bin.


    Gruß,


    BeetleJuice

    uuuups, nun geht´s ??? ähhhh...


    Ich habe den Start von VDR im runlevel vorgezogen um den VDR vor Samba, nfs, usw. starten zu können und siehe da, das LCD initialisiert. Jetzt stellt sich nur noch die Frage ob ich mir für die FB die setkeycodes-Tabelle sparen kann. Das kommt aber später...


    helau
    nun ja, ich habe mit ctvdr1 angefangen und bin bisher alle Versionen mitgegangen. Ich bin alles andere als ein Linux-Guru und das bischen Wissen das ich habe, das habe ich eben auf Debian... Bisher habe ich auch noch keinen Grund für einen Wechsel gefunden, da ich sowieso FullFeatured-Karten habe, benötige ich auch die Unterstützung für em8400 nicht.


    wilderigel
    ja, das plugin war/ist aktiviert. Warum es jetzt geht weiß ich aber leider nicht?

    Hallo Leute,


    ich bekomme das vdr-plugin-alcd leider nicht zum laufen. Ich kann es installieren, es startet auch aber weder das LCD wird initialisiert (steht weiterhin auf "Loading...") noch die FB kann ich benutzen. Bei ctvdr 6.2 lief das out of the box...


    Mit der FB habe ich mir über setkeycodes ein workaround geschaffen, aber für das Display tappe ich absolut im dunkeln. In welchen Log-Files könnte ich denn da nachschauen? Oder kennt evtl. schon jemand eine Lösung ?


    Gruß,


    BeetleJuice