Beiträge von uwe67

Zitat von gda

Das geht ja nun auch ohne Windows und man muss gar nicht erst warten bis das MKV fertig ist, man streamt es einfach zum Player.

Ja, Windows kommt auch nicht in meinem Haus. Die selbstgedrehten BluRays werden auf dem Server (12TB HD) als MKV geparkt und dann zu den ZBOXen gestreamt, so muss ich nicht ständig zum Server rennen und die DVD/BluRay einlegen (wenn Frau was anschauen möchte).

Zitat von seahawk1986

Bei vdr-developers.org gibt es noch das bluray-Plugin (http://projects.vdr-developer.org/git/vd…luray.git/tree/) das sollte die Scheiben auch direkt abspielen können (da libbluray selbst keinen Kopierschutz umgeht ist das kein Problem das zu nutzen).

Das habe ich schon probiert, mit mäßigem Erfolg, ist alles noch nicht ausgereift.

Mit ein wenig Phantasie in der Softwareauswahl und Umweg/Zeitaufwand können auch BluRays (2D und 3D) auf einem normalen VDR abgespielt werden.
Dazu muss allerdings das ganze Filmmaterial als MKV vorliegen.

Ich mach das hier z.B. so: Meine BluRays von meiner Videokamera konvertiere ich mit DVDVap (komerzielles Kaufprodukt für Windows) zur einer MKV-Datei. Die MKV-Dateien können dann mit den xineoutputplugin ganz normal unter Menüpunkt Medium im VDR abgespielt werden. DVBVap läuft unter Wine hervorragend, also ohne Windows.

Grüße

Hallo,

Ich schätze das tangiert uns peripher, da wir nicht die entsprechende Hardware haben, aber IR senden mit Trägerfrequenz 455KHz (B&O kompatibel) funktioniert jetzt mit dem yaUsbIR V3.

Grüße Uwe

Viele haben schon gefragt wie man den VDR wieder sauber über den Power-Taste der Fernbedienung runterfährt, so das auch die Aufnahmetimer zum automatischen aufwecken richtig programmiert werden.

Mein Lösung unter Suse ist eine kleine Erweiterung am Anfang der Datei /usr/lib/acpid/power_button (svdrpsend.pl-Pfad evtl. bei euch anders):

# /usr/lib/acpid/power_button
#


if [ `ps -C vdr | grep "vdr" | wc -l` -gt 0 ]
then 
   echo "vdr is running" 
   /usr/local/src/vdr/etc/svdrpsend.pl HITK Power
   exit 0
fi


....
<orginal>
....

bei yaVDR heißt die /etc/acpi/powerbtn.sh

Die Power-Taste der Fernbedienung darf nicht dem VDR bekannt sein, also die Zuweisung dieser Taste in der lirc.conf nicht definieren.

Grüße Uwe

Hallo Saman,

Zitat von Saman

was hältst du von einer 'Low Budget Version'?

Also nur Empfänger und Einschalter. Ich denke viele brauchen den Sender und die Tasten nicht wirklich.

Bei meinem, im Bau befindlichen, VDR-Client wäre das zB so.

Das habe ich schon mal alles durch gerechnet. Da sind zu wenig Stückzahlen hinter. Wenn ich jetzt da zwei verschiedene Platinen mache sind die Programmkosten(Bestücker), Rüstkosten, Schablonen und usw. zu hoch, da alles zweimal.

Zitat von Saman

Eine abgewinkelte Version (optional) der schwarzen Stiftleiste.

Meinst du sowas, wie im Bild im Anhang. Wer es benötigt kann es kostenlos als weiteres Bauteil mitbestellen. Ist halt schwer abzuschätzen obs passt mit der geraden Buchsenleiste.

Edit: Ach so du meinst die 4pol Stiftlesite, die kann ich auch optional dabeilegen wenn benötigt.

Gruß Uwe

Kann ich bestätigen, seit ungefähr eine Woche werden keine PM-Antworten per eMail versendet!

Grüße Uwe

louis

Habe da noch was gefunden, Einstellung "Schmales Aufzeichnugsmenü verwenden = nein" lässt sich nicht speichern. Nach VDR neustart geht die Einstellung verloren.

Der Bug liegt wohl in der setup.c. Hier fehlt das Speichern der Variable narrowRecordingMenu:

SetupStore("narrowSetupMenu", config.narrowSetupMenu);
+ SetupStore("narrowRecordingMenu", config.narrowRecordingMenu);
SetupStore("displayRerunsDetailEPGView", config.displayRerunsDetailEPGView);

Dieses Änderung habe ich noch nicht getestet.

Grüße Uwe

louis

Zitat von louis

if ((const cTimer *Timer = SortedTimers) && (SortedTimers->HasFlags(tfActive))) {

Macht leider ein Compilerfehler:

In file included from nopacity.c:140:0,
             	from skinnopacity.c:11:
displaymenu.c: In member function ‘void cNopacityDisplayMenu::DrawTimers(bool, int)’:
displaymenu.c:105:22: error: expected primary-expression before ‘const’
displaymenu.c:105:22: error: expected ‘)’ before ‘const’
skinnopacity.c:165:34: error: expected ‘)’ at end of input

Habe es so geändert:

if (const cTimer *Timer = SortedTimers[i]) {
	if (Timer->HasFlags(tfActive)) {
    	cNopacityTimer *t = menuView->DrawTimer(Timer, currentHeight);
    	if (initial)
        	if (FadeTime)
            	t->SetAlpha(0);
    	currentHeight += t->GetHeight() + menuView->spaceMenu;
    	if (currentHeight < maxTimersHeight) {
        	timers.Add(t);
    	} else {
        	delete t;
        	break;
    	}
	}
}

Dann funktioniert es (Inaktive Timer werden nicht mehr angezeigt).

Bleibt noch das Problem mit den Unterdirectories im Titel der Timeranzeige. Ich habe dein Patch etwas erweitert, mit dem Ergebnis dass die Unterverzeichnisse nicht mehr angezeigt werden.

Grüße Uwe

Zitat von louis

Uwe: kannst du bitte mal angehängten Patch ausprobieren?

Danke, Super, das war es! Evtl. die Folders und alle Sub-Folders wegnehmen.

Ähm, nicht ganz, weis aber nicht ob so gedacht ist: wenn der Timereintrag auf "Aktiv:nein" steht wird er trotzdem angezeigt. Soll das so sein?

Grüße Uwe

Zitat von louis

Wird denn im Timer Menü alles korrekt angezeigt?

Ja, dort wird alles korrekt angezeigt.
Habe gerade mal ins timersync-Plugin geschaut, soweit ich das Verstanden haben wird da folgendes gemacht:
Das timersync-Plugin ist ganz einfach gestrickt (nur 455 Zeilen Code). Es kopiert Timeränderungen über SVDRP hin und her, auf dem Client wird dann das VDR-Timerobject direkt gefüttert (oder per lokalen SVDRP, weis nicht so genau) mit den Daten von SVDRP.

Grüße Uwe

Zitat von louis

Existieren die Timer zwei mal oder werden die auf den Server geschoben und dann gelöscht?

Die Timer sind nur auf dem Server vorhanden. Wie im Bild oben zu sehen fehlt ja nur nur ein Teil der Information, die Uhrzeit und der Sender werden ja angezeigt.
(jo, LCARS hat das Problem auch).

Grüße Uwe

Hallo louis,

beim Testen mit einem Client ist mir aufgefallen, das die Programminfos bei der Timerliste rechts im Hauptmenu nicht angezeigt wird. Ich habe dann mal umgeschaltet auf EnigmaNG, dort sind die Sichtbar. Schalte ich das Plugin timersync (nicht remotetimers) ab dann sind die Programminfo sichtbar (allerdings wird dann die Aufnahme lokal auf dem Client gestartet, was ich aber bei einem Server-Client System nicht machen möchte).

Wo liegt die Ursache?

Grüße Uwe

Zitat von Keine_Ahnung

uwe67: Mein Gehäuse hat ne blaue Hintergrundbeleuchtung (für den Digitainer Schriftzug), basierend auf ner Plexiglasplatte mit 2 eingegossenen LED und zwei Wiederständen. Das wird direkt an 5 Volt angeschlossen. Kann ich das auch direkt an PIN 7/8 von ST6 stecken? Oder ist die Leistung dort nur auf wenige mA zum Schalten beschränkt und nicht für dauerhafte hohe (naja, mehr oder weniger, mehr als 60mA werden es wohl garantiert nicht sein) Stromentnahme geeignet?

Output 1 bis 4 können maximal 15mA treiben. Wenn du da etwas dranhängst (>15mA) dann über einen Transistor schalten.

Grüße Uwe

Neues von der yaUsbIR-Front:

- zur Zeit ist ein Kollege dran einen Treiber für WinLIRC zu schreiben, es steht noch offen wann dies fertig wird. Eine proprietäre Windowsversion (für den Enduser eher ungeeignet) ist schon lauffähig.
- yaUsbIR V3 wird gerade auf zusätzlich 455KHz senden erweitert, ein Test mit echten B&O-Geräte steht in der nächsten Woche an.

Grüße Uwe

Zitat von Paulaner

Über einen Befehl kann ich ja die rote LED komplett abschalten bzw. auch wieder einschalten.
Gibt es auch einen Befehl, wo die LED im Normalfall AUS ist und wenn ein IR-Befehl kommt entsprechend Blinkt?
Also das umgedrehte Verhalten, wie jetzt, wenn ich die LED auf EIN schalte!

Jain, die rote LED ist nur für Konfiguration/Debugzwecke und sollte später im eingebauten zustand des yaUsbIR-Moduls nicht mehr sichtbar sein.
Es gibt aber einen Anschluss für eine externe LED, die dann nur leuchtet wenn der yaUsbIR eine Ferbedienung sieht. Ich habe bei mir da einfach die Powerled vom Rechnergehäuse angeschlossen.

Grüße Uwe

Zitat von Paulaner

Warum nimmst Du einen TSOP38238, wo doch eigentlich der RC-5-Code eine 36kHz Burstfrequenz verwendet? Wäre da nicht ein TSOP38236 besser?

Nicht jeder benutzt RC5 (36KHz), es gibt da Leute möchten einen Sony (40KHz) steuern (zum Anlernen nötig), oder haben eine 40KHz Fernbedienung...
Der 38KHz Empfänger liegt genau dazwischen und deckt den 36-40KHz Bereich ab.

Ein TSOP38236 kannst du natürlich verwenden, wirst aber kein Unterschied bemerken, ich habe es mit einen Oszilloskop mal nachgemessen.

Grüße

Paulaner

Du machst sachen... 8m

Beim yaUsbIR V3 wird ein TSOP38238 ausgeliefert, der hat eine andere Pinbelegung! Der Stecker auf der Platine wurde entsprechend angepasst.
Mach aber bei einem langen Kabel eine 10uF/16V direckt am IR-Empfänger an VCC und GND dran, sonst kann der IR-Empfänger nicht richtig arbeiten.

Grüße Uwe

Zitat von Keine_Ahnung

Das muss sich wohl uwe nochmal anschauen, vermutlich wird einfach ne schliessende Pause weggetrimmt?

Da wird nichts getrimmt.

Zitat von Keine_Ahnung

Magst du mal das Protokoll Posten was yaUSBir nutzt?

Mache ich gerne:
yaUsbIR sendet die Pulse und Pausen 1:1 zu IR-LED wie sie von lirc aus den lircd.conf geliefert/berechnet werden. Die Daten die im lirc zum USB gesendet
werden sind nichts anders wie man es mit mode2 sieht, nur umgekehrt.
Die Werte (Pulse und Pausen) werden durch 13 (bei 38Khz) dividiert, und noch ein Bit (0x8000) angefügt ob es ein Pulse oder eine Pause ist. Bei Pulse wird die IR-LED mit 38KHz (hier im Beispiel) gepulst, bei einer Pause die entsprechende Zeit abgewartet die von lird gesendet wurde (IR-LED ist dabei aus). Das ist das ganze Protokoll. Es obliegt dem lirc wie die Daten (Pulse und Pausen) generiert werden, der ya_usbir-Treiber in lirc konvertiert die Daten (eigendlich nur PulsePause/13) und sendet sie dann zum yaUsbIR über USB.

Die intern eingebaute Fernbedienung in der yaUsbIR-Hardware macht das genauso, nur hier werden die gelernten Daten aus dem Flash genommen und zur gleichen IR-Senderoutine, wie bei den Daten über USB, gesendet.

Das Sony-Protokoll hat 12, 15 und 20 Bit.

Grüße Uwe

Zitat von 3PO

Schade ist halt nur, dass der besagte Patch, wie weiter oben schon geschrieben, leider nicht funktioniert

Du meinst den bei Beitrag 122, der kann nicht gehen wie ich gestern Nacht festgestellt habe.

Zitat von Keine_Ahnung

D.h. im schlimmsten Fall geht die Diode kaputt und nicht yaUSBir? Um die Frage gehts mir eigentlich.

Nein, da geht nichts kaputt (habe ich schon mal irgendwo gesagt, aber hier im Thread ist es schon sehr unübersichtlich geworden).
Es ist eine Stromquelle mit Begrenzung auf max. 100mA, selbst ein Kurzschluss macht nichts am Sendeausgang.

Grüße Uwe