Beiträge von Torsten/WarEagle

    Hi,


    ich plane derzeit mir das T6963C-Display (http://www.vdr-wiki.de/wiki/index.php?title=HowTo_6%22_gLCD) zu besorgen und habe aber vorher noch ein paar Fragen...
    Mich interessiert was ich wegen der Displaylaufzeit machen könnte. Mein vdr läuft 24h und da möchte ich das Display eigentlich in 3 Stufen laufen lassen.
    a) aus
    b) Hintergrundbeleuchtung aus
    c) an


    Am liebsten wäre es mir, wenn ich das per graphlcd steuern könnte, aber das ist denke ich 3 Schritte zu weit :)


    Da ich mir (http://www.neuhold-elektronik.…info.php?products_id=1929) das Display mit Gehäuse und Steuerplatine holen wollte wäre es auch eine Idee zwischen Platine und den Poti der für die Helligkeit zuständig ist zu gehen.


    Bei der Umbauanleitung wird vorgeschlagen Pin 4 und 5 zu verbinden, damit die Hintergrundbeleuchtung dauerhaft aktiviert ist.
    http://www.on-luebeck.de/LCD_H…romversorgungsstecker.jpg
    Wenn ich nun das Kabel Pin4-Pin5 zu einem Schalter führe, kann ich damit dann ohne Nebenwirkungen die Hintergrundbeleuchtung ein/ausschalten, oder handele ich mir hier Probleme durch das umschalten um laufenden Betrieb ein?


    Macht das Sinn, oder gibt es hier schönere Möglichkeiten?
    Wie würde ich das Display denn am sinnvollsten komplett deaktivieren können? Eine softwarelösung wäre hier wunderbar, dann könnte man das Ding per cron nachts abschalten.


    Ich weiss ich habe hier schon wieder Wünsche.... :)
    Für mich ist der Elektronikkrams neu, also bitte ruhig für Vollpfosten erklären :)


    Gruß


    Torsten

    Ich kenne mich mit gettext und der Arbeitsweise nicht aus, aktuell gibt es beim vdr ja 3 übersetzungswege.

    • tr()
    • trNOOP()
    • trVDR()


    Mit tr() übersetzt man direkt, das trNOOP ist nur ein dummy für die Nutzung von tr() wenn hier Variablen übergeben werden und die Einträge in den po-Dateien erzeugt werden können, also eine Art "Hallo ich muss auch Übersetzt werden"-Flag.
    trVDR scheint dann ja die "Übersetzungsdomäne" zu ändern.
    Wäre es nicht eine Idee immer trVDR() (oder anderer Name) zu nehmen und hier folgendes Vorgehen dran zu hängen?
    Zur Laufzeit: Immer übersetzen
    Bei make i18n: zuerst im Plugin schauen, ansonsten in VDR schauen
    Damit hätte man nur noch eine tr-Methode, hätte aber alles abgedeckt, ausserdem hätte man ein Durchsichtsprinzip vom Plugin in Richtung VDR, man müsste nur in Spezialfällen aufpassen, halt wenn man für ein Wort eine andere Übersetzung als im vdr selber haben möchte, aber da kann man sich ja auf viele Arten aushelfen.


    Ist nur ein wenig Brainstorming um die Übersetzungsmethoden zu vereinheitlichen.

    Dank HolgerAusB hier nun der Patch für noepgmenu-0.0.4.


    Der Patch für das Plugin hat einen Fehler, der neue wird bald hier stehen, wer ihn vor dem 17.10.2007 heruntergeladen hat, bitte den neuen einspielen.
    Es ist nur der Pluginpatch betroffen, nicht der noEPG-Patch.


    Erklärung:
    Das Problem war, dass er teilweise die KanalID-Einträge "verstümmelt" hat, sie waren dann zwar ungültig, jedoch haben sie die Liste vollgemüllt. Insgesamt arbeitet der Patch auch scheinbar problemlos, nur mit dem korrigierten ist das Problem vom Tisch :)


    Wenns mit dem auch Probleme geben sollte, bitte melden :)
    Achso die noEPGList-Einträge haben sich im Format geändert, die Angaben müssen neu gemacht werden.

    Zitat


    Ich könnte noch einige Dinge aufzählen, wobei es mir hier nicht um die Probleme an sich geht, sondern einfach um die immer noch zahlreichen "kleinen" Probleme, die den VDR nicht aus der Ecke "Bastel-Lösung" rücken lassen.


    Schreib ruhig die Sachen rein die dich stören, denn mit einem "da ist noch mehr was mich stört" ist es immer ein großes Gerate wo geschraubt werden soll :)


    Was die GUI angeht, so finde ich das kein Problem, schau dir mal fertige Kisten an, da ist der VDR aber (gerade mit Skin-Plugins) ein graphisches Monsterwerk :) Die reduzierte Darstellung ist ja auch technisch bedingt, die DVB-Karten geben einfach kaum mehr her, da der Speicher und die Leistung arg limitiert sind. Wenn man nun aber eine Graphikkarte mit TV-Out und einen schnellen Prozessor für die Menüberechnung vorraussetzen würde, dann wäre das wieder eine viel viel höhere Hardwareanforderung. Gerade beim VDR ist ja das schöne, dass es mit sehr alter Hardware auskommt.

    Das hier hatte Klaus mal in einem ML-Beitrag geschrieben

    Zitat


    Thanks. "TV5 Monde" on Astra 19.2E also broadcasts FTA and with occasional subtitles:


    TV5MONDE EUROPE;TV5MONDE:11597:vC56:S19.2E:22000:45:46:3602:0:10060:1:1026:0


    I'm almost done with subtitle support. During the past few weekends the
    weather was just too nice to work too much on VDR... ;)

    VDR developer version 1.5.10 is now available at


    ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.10.tar.bz2


    A 'diff' against the previous developer version is available at


    ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.9-1.5.10.diff



    WARNING:
    ========


    This is a *developer* version. Even though *I* use it in my productive
    environment, I strongly recommend that you only use it under controlled
    conditions and for testing and debugging.



    The changes since version 1.5.9:


    - Implemented handling DVB subtitles (thanks to Marco Schlüßler, and also to
    Pekka Virtanen for writing the subtitle plugin, which helped in implementing
    subtitle handling in VDR).
    - The new remote control key "Subtitles" can be used to bring up the list
    of available subtitles.
    - The new setup option "DVB/Subtitle languages" can be used to define the
    preferred languages for subtitles.
    - Fixed selecting the audio track when pressing Ok in the Audio menu (thanks
    to Marco Schlüßler).
    - Implemented display of DVB subtitles in live viewing mode.
    - Implemented subtitle track selection.
    - Implemented bitmap color reduction and shrinking to display subtitles even
    on devices that can't display the necessary number of colors.
    - Added compatibility mode for playback of recordings made with the subtitles
    plugin (with some help from Rolf Ahrenberg).
    - The new setup option "DVB/Subtitle offset" can be used to shift the location
    of the subtitles in the vertical direction.
    - The new setup options "DVB/Subtitle foreground/background transparency"
    define an additional level of transparency for the foreground and background
    color of subtitles.
    - Existing recordings made with the subtitle plugin can be given an 'X' record
    in their info.vdr file, so that subtitles can be automatically selected upon
    replay, according to the preferred language setup, as in
    X 3 03 ger deutsch
    (see vdr.5). Note that these entries need to be added in the proper sequence,
    so that they correspond with the actual track languages in the recording.
    - Now generating translation files without line numbers to avoid unnecessarily
    large diffs. Plugin authors may want to replace the -F option with
    --no-location in the xgettext and msgmerge calls in their Makefiles.
    - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
    - Added a missing Channels.SetModified(true) call when deleting or moving a
    channel in the Channels menu (reported by Halim Sahin).
    - Fixed a missing '-' at the next to last line of SVDRP help texts (reported by
    Denis Knauf).
    - Added a missing SetVolumeDevice() call in cDevice::SetPrimaryDevice() (reported
    by Reinhard Nissl).
    - Fixed a crash when pressing Left while at the first character of a cMenuEditStrItem
    (thanks to Christian Wieninger).
    - Only creating a new cDvbOsdProvider in cDvbDevice::MakePrimaryDevice() if 'On'
    is true (i.e. this device is being made the primary device).
    - Updated the Italian OSD texts (thanks to Diego Pierotto).
    - Fixed handling reallocated memory in cCharSetConv::Convert() (reported by Udo
    Richter).
    - Fixed a new[]/delete mismatch in cMenuEditStrItem::LeaveEditMode() (thanks to
    Udo Richter).
    - Implemented sending all frames to devices that can handle them in fast forward
    trick speeds (thansk to Timo Eskola).
    - Updated the Hungarian language texts (thanks to Thomas Günther).
    - Fixed description of DeviceSetAvailableTrack() and cReceiver(), and added an
    example ~cMyReceiver() in PLUGINS.html (thanks to Marco Schlüßler).
    - Improved the description of where logging goes in the INSTALL file (thanks to
    Elias Luttinen).
    - Added a note about how to initiate internationalization support to the
    README.i18n file. The Makefile generated by the 'newplugin' script now has the
    'i18n' target automatically create an initial 'po/pluginname.pot' file.
    Plugin authors may want to add the '$(I18Npot)' dependency to the 'i18n'
    target in their Makefiles, as in
    i18n: $(I18Npot) $(I18Nmo)
    (based on a suggestion by Torsten Kunkel).
    - Removed a duplicate ',' from the ca_ES.po file (thanks to Thomas Günther).
    - Added the 'ß' character to the "allowed charcaters" in the de_DE.po file
    (suggested by Thomas Günther).
    - Made the default copy ctor of cRecording private (thanks to Markus Hahn).
    Same for the assign operator.
    - Added cRecording::Undelete() (based on a patch from Markus Hahn).
    - Added cDevice::CloseFilter() to allow a device to have complete control over
    both opening and closing section filters (thanks to Rolf Ahrenberg).
    - Some fixes to PLUGINS.html (thanks to Rolf Ahrenberg).



    *When reporting problems, please don't reply to this message!*
    Create a new thread instead, using a descriptive subject!


    Have fun!


    Klaus

    Ja du hast vollkommen recht, da stimmt was im diff nicht. Mein Fehler, ist gestern irgendwas durcheinander geraten.
    Ich lade gleich neue hoch, sorry.


    So hat ein wenig gedauert sorry für den Fehler, irgendwie ist mir beim letzten Transfer ein teil des Patches verloren gegangen, müsste aber nun alles wieder drin sein.

    Bei den aktuellen Versionen hat sich die Übersetzungsart geändert, vdr sucht nun in den gettext-dateien (po-Unterverzeichnis).
    Wenn das Plugin nicht angepasst wurde, dann kann man sich halbwegs mit dem von dir erwähnten Perlscript helfen, das einfach mal aufrufen ud dann erzeugt es die gettext-dateien die für die Übersetzung gebraucht werden.

    Für einen reinen VDR reicht die CPU problemlos aus, die Arbeit erledigt die FF-Karte für dich.
    Auch das hören von MP3 müsste problemlos gehen, erst bei der Wiedergabe von DivX etc könntest du leichte Probleme bekommen.
    RAM brauchst du eigentlich auch keine 512, sie schaden aber nicht.
    Für den Anfang wirst du mit dem System eigentlich alles machen können, ob du auf lange sicht zufrieden sein wirst weiss ich nicht, denn wie schon angedeutet, DivX-Wiedergabe könnte ein Problem werden, die Umrechnung von Aufnahmen auf DVD wird recht lange dauern etc. Du hast also einige Komforteinschränkungen, aber ich weiss nicht ob du das alles überhaupt benutzen wirst.
    Wenn du die Sachen rumliegen hast, dann nimm sie ganz beruhigt erstmal.


    Der VDR belastet die CPU fast gar nicht, die gesamte Arbeit der TV-Aufnahme und Umrechnung übernimmt die FF-Karte, aher wirst du vielleicht 5-10% CPU-Last haben (für vdr).


    Auch die beiden Karten laufen problemlos nebeneinander, du hast dann halt 2mal ARD, 2mal ZDf etc. Dieses kann vdr von Haus aus, brauchst dir also keine Gedanken zu machen.


    p.s.
    http://vdr-wiki.de/wiki/index.php/Mischsysteme

    Hi,


    hier ein kleiner Patch welcher es erlaubt das primäre DVB-Gerät (PrimaryDVB) beim vdr-Start anzugeben.


    Warum sollte man das brauchen?
    Mich hat es einfach gestört, dass vdr intern im Setup den Wert auf 1 setzt wenn man mal vdr mit nur einer Karte gestartet hat. Wenn mal ein Test mit -D gelaufen ist, oder mal der Treiber Probleme machte, dann ist gleich das OSD weg und man muss die setup.conf per Hand anpassen. Mit dem neuen Schalter -R (-P -p -d -D waren schon weg :/ ) kann man nun einfach immer das "echte" Gerät angeben, also bei mir dann immer "-R 2". Wenn nur eine Karte drin ist, dann nimmt er automatisch die kleinste mögliche, wenn aber wie im Normalfall beide Karten drin sind, dann nimmt er die "richtige".
    Jepp, man könnte das auch per Script vor dem VDR-Start machen indem man die setup.conf entsprechend anpasst, aber das wäre doch langweilig :)


    Vielleicht kann es ja noch jemand gebrauchen.


    Gruß


    Torsten


    *edit*
    p.s. beim patchen bitte -p2 und nicht nur -p1 angeben.

    Wäre möglich ja, ich baue da die Tage mal was zusammen was schöner ist, aber als Schnellösung müsstest du eigentlich nur die Auswertung umdrehen.
    Ändere mal in der channels.c den Code der keinEPGScan-Funktion in das hier:

    Code
    bool cChannels::keinEPGScan(tChannelID kanalID)
    {
      bool rc=true;
    
    
      if (strstr(::Setup.noEPG,kanalID.ToString())!=NULL){
        rc=false;
      }
      return rc;
    }


    ist nur true und false vertauscht. Müsste klappen, ist aber unschön und nicht getestet, halt ein Schnellschuss :)

    Hallo allerseits,


    ich habe den noEPG-Patch einmal überarbeitet.
    Ein grosses Problem des Patches war, dass er fix auf 999 Zeichen eingeschränkt war. Es werden beim Patch die KanalIDs gespeichert, also ca. 25 Zeichen pro Kanal damit also (999/25) ca. 40 Kanäle maximum.
    Wenn man nun das EPG für mehr Kanäle ausschalten möchte, dann musste man den Patch ändern. Da ich die Informationen automatisch per script aus den tvmovie2vdr-Dateien übernehme bin ich schon oft darauf reingefallen.


    Lokal habe ich es daher schon auf 9999 stehen gehabt (also 400 Kanäle). Aber irgendwie war mir das immer zu unsauber.
    Die neue Version arbeitet dynamisch, die festlegung auf 999 Zeichen ist damit entfallen.


    Für das Plugin gibt es auch einen Patch der dieses Verhalten auch dort einbaut.


    Ich hoffe ich habe keine allzugrossen Speicherlecks drin :/ , bitte meldet euch wenn es Probleme gibt!


    Viel Spass


    Torsten

    Hi,


    die Lautstärkeregelung ist beim vdr ja fest auf 5 "Einheiten" gesetzt, im Chat kam neulich die Frage hoch, ob man das nicht auch konfigurabel machen könnte.
    Hier ist der Patch dafür, es gibt danach eine neue Option in den Einstellungen wo man den Wert von 1 bis 10 umstellen kann, der Standardwert ist auf 5 (wie bisher) gesetzt.
    Das ganze ist für 1.5.9 gemacht, sollte aber abgesehen von der Übersetzung auch für andere Versionen arbeiten.


    Gruß


    Torsten

    Hi Oliver,


    danke für die Ausführungen, ich habe eh so einen PCI-Lüfter über den Karten hängen, für einen Luftzug ist also gesorgt.


    Allerdings habe ich gerade das nächste Problem, und zwar steht im Wiki etwas von 15 ohm und 5 Watt, jedoch sieht der Widerstand in http://www.vdr-wiki.de/wiki/in…pannungsmod_tunermod4.jpg nach einem normalen 2 Watt-Widerstand aus.


    Weisst hier jemand genaures?


    Auch der Widerstand für das Überbrücken der PINs ist arg schwer zu erkennen :/