einen Rauschabstand von 23%
Das ist ein so unterirdischer Wert, dass ich kaum glauben kann, dass Du damit überhaupt irgendwas empfängst. Vielleicht liefert der Treiber auch einfach keine richtigen Werte. Was zu der Frage führt, ob Du den richtigen Treiber hast. Ich bin da bei DD und insbesondere deren Sat devices nicht so im Thema. Ist der Treiber im Mainline-Kernel, oder gibt es einen von DD aktueller gepflegten proprietären Treiber?
Würde ja auch nichts bringen, da die Konfiguration vor dem Kompilieren individuell vorgenommen werden muss
aus einem script heraus mit
/usr/local/bin/vdr-dbus-send.sh /Remote remote.HitKey string:'Power'
die Box auch herunterfahren,..
was ist der Vorteil ggü. svdrpsend HITK Power?
warum nicht einfach die PVR-150 unter Windows nutzen - geht ootb.
Ich hab es nicht selbst probiert, aber im Gleitz-Forum hatte jemand berichtet, dass die Einstellungmöglichkeiten beim Windows-Treiber limitiert sind und es aufgrund nicht abschaltbarer Rauschfilter zu Geisterbildern kommt. Das ist ein Effekt, der auch unter Linux auftreten kann - da kann man aber jeden einzeln Filter regeln und das Problem lösen.
Nochmal zum python-Script ps3remote.py, das für die Tastenwiederholungen sorgt: Ein kleinerer Wert als 150 für die repeat Rate macht die FB noch schneller. Ich betreibe sie auf der Tanix jetzt mit -r 100. Man muss in den vdr-Einstellungen dann darauf achten, dass unter "Fernbedienung Wiederholverzögerung" ein repeat delay von 300 (Standardwert) eingestellt ist, sonst prellt die FB. Den Wiederholintervall kann man dort auch kleiner als 100 setzen. Ich arbeite mit
CodeRcRepeatDelay = 300 RcRepeatDelta = 50Die Fernbedienung rast unter vdr und prellt nicht!
Wenn man nun zu Kodi wechselt, kann es sein, dass die FB dort zu schnell ist und Tastendrücke doppelt ausgeführt werden. Dafür kann man in .kodi/userdata/advancedsettings.xml eine Verzögerung mit dem Eintrag remotedelay im Bereich von 1-20 konfigurieren:
Code<advancedsettings version="1.0"> <showexitbutton>true</showexitbutton> <cache> <buffermode>1</buffermode> <memorysize>339460608</memorysize> <readfactor>20</readfactor> </cache> <remotedelay>3</remotedelay> </advancedsettings>(Die anderen Einträge für showexitbutton und cache waren schon drin - ist wohl CoreElec Standard. Wenn die Datei noch nicht vorhanden ist, muss sie angelegt werden.)
Für diejenigen, die VDR*Elec benutzen: Dort ist der Parameter -r150 in /usr/local/bin/start_ps3remote.sh fest eingetragen. Diese Datei ist Teil des squashfs-System und kann nicht bearbeitet werden. Die Lösung sieht so aus:
Einen eigenen systemd-Service amremote.service unter storage/.config/system.d anlegen. Inhalt:
Gleichnamige Services in diesem Ordner haben Vorrang gegenüber denen in /usr/lib/systemd/system.
Dann in /storage/.config/vdropt/ eine neue Datei start_ps3remote.sh anlegen und ausführbar machen. Inhalt:
Die Änderungen gegenüber den Originaldateien habe ich jeweils fett markiert.
Damit die Tasten danach in Kodi nicht prellen, muss dann noch die Datei /storage/.kodi/userdata/advancedsettings.xml um einen Eintrag ergänzt werden. Auf einem frischen VDR*Elec war sie noch nicht vorhanden, daher hier der komplette Inhalt:
<advancedsettings version="1.0">
<remotedelay>3</remotedelay>
</advancedsettings>Das sind alles Empfehlungen, die für meine Universal-Fernbedienung mit den darauf genutzten NEC-Codes gelten. Es ist durchaus möglich, dass Eure FB schneller ist und das gar nicht braucht - oder danach sogar heftig prellt. Wer das Gefühl hat, dass die FB gerne noch etwas schneller sein dürfte, sollte es ausprobieren!
Gibt es für DVB-T2-HD und DVB-C auch eine Lösung? Ich möchte gern eine Quadtunerkarte für DVB-T2 und einen Dualtuner-USB-Adapter für DVB-C einbinden. Da der Tuner beider Geräte für sowohl DVB-T2 als auch DVB-C taugt, würden sie sich beide zuständig fühlen. Jedoch liegt bei einem Gerät das Antennensignal für DVB-T2 und beim anderen DVB-C an.
Du kannst den Quellcode damit vor dem Kompilieren so abändern, dass ein device nur für DVB-T2 oder DVB-C zur Verfügung steht. Du müsstest mal schauen, ob Du die device-Numerierung irgendwie beeinflussen kannst, damit sie sich nicht ständig ändert, je nachdem welcher Treiber zuerst geladen wird und mit der Initialisierung fertig ist. Wurde hier schon mal diskutiert:
der shutdown-wrapper vom VDR läuft noch ins Leere, da es kein dazu passendes shutdown-script gibt, das in den shutdown
Prozess integriert ist,..
Einen shutdown-wrapper gibt es doch bei VDR*Elec gar nicht. Der wird nur benötigt, wenn vdr nicht als root läuft - was hier aber der Fall ist.
Was beim Ausschalten passieren soll, muss vdr mit dem shutdown-Parameter beim Start gesagt werden. Ergänze dazu in /storage/.config/vdropt/conf/vdr.conf eine Zeile:
-s /storage/.config/vdropt/vdrshutdown.shDann leg in /storage/.config/vdropt eine Datei vdrshutdown.sh an und mache sie ausführbar. Inhalt:
#!/bin/bash
NextTimer=$(($1 - 600 )) # 10 minutes earlier
bash -c "echo 0 > /sys/class/rtc/rtc0/wakealarm"
if test $NextTimer -gt "0"; then
bash -c "echo $NextTimer > /sys/class/rtc/rtc0/wakealarm"
fi
halt -pDas sollte schon reichen. Zum Testen dran denken, dass der Timer frühestens in 11 Minuten starten darf. Auf meiner Tanix TX3 hat das so geklappt.
Die Frage ist eher ob mini73 noch weiter am Plugin arbeiten will. Mein letzter Stand war, dass er gar keinen VDR mehr nutzt. Ich habe jetzt erstmal das vdr-projects Repo auf https://vdr-projects.github.io/ verlinkt.
Ja, er sagte damals schon, dass er da eigentlich nichts mehr machen möchte. Aber dann lieber ganz vom Netz nehmen, solange es noch eine aktueller gepflegte Quelle gibt. Ohne den letzten Patch ist Frust vorprogrammiert, denn man wird nie auf den Videoeingang umschalten können. Und es kommt ja doch immer mal wieder einer aus der Deckung, der VHS digitalisieren möchte.
Ein paar Links dazu:
Es geht auf einem Linux-Rechner grundsätzlich auch ohne pvrinput, obwohl die Einstellungsmöglichkeiten über pvrinput einfacher sind. Die Standardeinstellung des temporalen Filters ist nach meiner Erinnerung 8 und kann mitunter zu Geisterbildern führen. Das sollte auf 6 oder 4 geändert werden. Dazu vielleicht noch den Ton runter (100% ist zu laut) und die Bitrate gerne von 6 MB/s auf 8 oder mehr hochsetzen.
Ich empfehle eine Nachbearbeitung der erzeugten mpg oder ts-Dateien mit Avidemux, um die Störzone am unteren Bildrand zu beseitigen. Siehe
https://gleitz.info/forum/inde…&postID=466380#post466380 Ich habe dabei immer darauf geachtet, dass sich das Seitenformat nicht ändert. Also wenn man unten was entfernt, muss eitlich soviel weggeschnitten werden, dass das Verhältnis wieder 1,25 ist. Oder man maskiert den unteren Bildrand schwarz.
Das geht leider nicht ohne Neuencodierung, wozu sich h264 oder h265 anbietet. Ganz wichtig: Das Eingangsformat ist bei einer Umwandlung 720x576. Das ist ein Seitenverhältnis von 1,25. Wir brauchen für eine formatgerechte 4:3-Wiedergabe aber 1,33. In Avidemux muss dazu für das Ausgabeformat beim mkv-Muxer "Bildformat erzwingen" angekreuzt und eine DAR von 4:3 vorgegeben werden. Einen deinterlacer wie yadif würde ich in Avidemux auch noch aktivieren.
M-Reimer: Vielen Dank! Jetzt fehlt der letzte Fix nur noch im git von mini73 bei flensrocker. Vielleicht mag mini73 das ja dort auch noch nachpflegen?
Früher hat man so eine Reihenverkabelung tatsächlich wohnungsübergreifend gemacht. Heute ist das bei neuen Anlagen nur noch innerhalb einer Wohnung zulässig.
Jede Dose hat eine Durchgangsdämpfung, deshalb kommt bei der letzten Dose der Kette am wenigstens Pegel an. Am Anfang der Kette sind es entsprechend mehr. Da nun Dein TV aber nur 80% STR anzeigt, bleibt das Verhalten der Cine ein Mysterium. Entweder Karte defekt oder Treiber verbugt.
Gegen die Dose ist absolut nichts einzuwenden. Sie gibt 5-2150 MHz aus und ist definitiv digitaltauglich. Daran kann es nicht liegen. Wo führt die abgehende Leitung hin? In eine andere Wohnung oder in eine zweite Dose in Deiner Wohnung?
Die Anschlussdämpfung von 15 dB ist schon recht hoch (meist werden 10 dB Dosen verbaut), aber bei offenbar hohen Pegelverhältnissen anscheinend bewusst gewählt.
Wegen dem WinTV Stick hab ich mal geschaut, anscheinend hat den gerade kein deutscher Händler auf Lager (oder kriegt ihn erst Ende Dezember wieder rein)
69,99 Euro portofrei und sofort lieferbar bei Amazon.
Die quadHD ist sicherlich auch interessant, aber auch fast doppelt so teuer. Und Du hast im PC wieder das potentielle Elektrosmog-Problem. USB-Tuner sind zukunftssicherer, denn der Trend geht weg von großen HTPC-Boliden hin zu kleinen ARM-Boxen.
Die Hausverwaltung sollte sich nicht nur auf die Dose konzentrieren, sondern muss das Problem ganzheitlich betrachten. Dazu gehört der Antennenverstärker, die Pegeljustage und eine Messung der Bitfehlerrate. Wenn Du im Vorwege Argumentationsfutter haben willst, könntest Du mal schauen, welche Dose verbaut ist. Also Plastikblende abschrauben, 2 Schrauben lösen und den Doseneinsatz aus der Unterputzdose rausziehen. Am besten ein paar Fotos von Vorder- und Rückseite machen. Mit etwas Glück lassen sich Hersteller und Typ noch ermitteln und man findet die technischen Daten im Netz. Dann kann ich Dir mehr sagen. Gibt es einen Hausmeister, der Dir Zugang zum Antennenverstärker verschaffen kann?
Solange das Problem nur die Cine hat und der TV einwandfreien Empfang hat, kann eine Reklamation nach hinten losgehen, wenn nicht schon anhand der verbauten Teile von vornherein klar ist, dass diese heutzutage ungeeignet sind.
sieht man denn dann was im Log? Spontan würde ich auf nicht freigegebene Ressourcen tippen. CoreElec scheint ja kein Pulseaudio zu unterstützen und spricht alsa direkt an.Beim Wechsel vdr zu Kodi wird softhdodroid ja detached und müsste dabei das alsa device freigeben, denn Kodi hat nie Probleme mit dem Ton. Umgekehrt wird bei Rückkehr zu vdr Kodi komplett beendet und gibt ebenfalls die devices frei.
Wie das nun im Zusammenspiel mit dem Web-Plugin funktioniert - keine Ahnung. Greift das auf alsa zu oder sendet es den Ton an den vdr?
Hast du schon eine Idee dazu? Ich hätte ja erwartet, daß dann bei einem Senderwechsel der Ton wieder kommt (Initialisierung und so). Aber der bleibt tatsächlich weg.
Das Problem kenne ich so bisher nicht. Wann hatte jojo das gepostet? Tritt das aktuell wirklich noch auf?
Ich meine mich allerdings zu erinnern, dass -warum auch immer- ab und an in den vdr-Einstellungen die Lautstärke auf 0 gesetzt war - obwohl ich die Lautstärke gar nicht über den vdr regele. Ein vdr-Restart hat dann solange nichts geholfen, bis ich in den vdr-Einstellungen die Lautstärke auf 100% beim Start gesetzt hatte (InitialVolume = 255). Aber das ist wahrscheinlich ein anderes Problem.
Und diese Ausreißer und die Probleme mit Servus TV bestehen nur beim Durchschleifen durch die Cine?
Mein Rat: Hol Dir einen WinTV dual HD Stick. Ab Kernel 4.17 läuft der einwandfrei. GGf. muss der Transfermodus noch auf bulk geändert werden. Ich habe meine Cine CT V6 schon vor Jahren rausgeschmissen. Der Stick sitzt mit einem Adapter direkt auf dem Ausgang meines F-Verteilers. Statt eines Antennenkabels wird ein USB-Verlängerungskabel (eine Seite A-Stecker, andere Seite A-Buchse) zum VDR geführt. Vorteil ist nebenbei, dass man den Empfänger nicht mehr in der PC-Elektrosmog-Hölle sitzen hat.
Im schlimmsten Fall macht der Stick bei Dir auch Empfangsprobleme. Dann bist Du zumindest schlauer. Entweder schickst Du ihn zurück oder machst Dich mit der Hausverwaltung an eine Problembehebung - und hast - wenn das klappt - hinterher 4 Tuner statt 2.
Das ganze ist sehr mysteriös, vor allem weil der TV mit Signalstärke 80 und Qualität 100 ja völlig konträre Werte anzeigt und offenbar auch keine Probleme hat. Und der hängt wirklich an der gleichen Dose?
Selbst wenn der TV einen Tuner haben sollte, der mit sehr hohen Pegeln besser zurechtkommt, sollte man meinen, dass er dann als Signalstärke nicht 80 sondern 100 anzeigt. Es stellt sich daher die Frage, ob der DD-Treiber überhaupt brauchbare Werte liefert. Und auch einen Defekt der Karte würde ich nicht ausschließen. Hast Du die Möglichkeit, sie einzeln oder mit dem kompletten VDR an einem anderen Kabelanschluss zu testen? Oder zum Vergleich ein Windows-System aufzusetzen?
Sollte es tatsächlich ein Problem mit dem Kabelsignal sein (wie gesagt, der TV spricht dagegen), dann fielen mir hier Dinge ein wie
Bei mir zeigt femon unter STR zwischen 68 und 70 dBuV an. Also positive Werte und dezibel Mikrovolt. Schau mal ob Du mit kleinerer Schrift und breiterem OSD die komplette Anzeige der Maßeinheit hinkriegst. Wenn es dBm sind, bin ich bei SHF. Dann ist das Signal zu hoch.
CNR ist bei mir 35 bis 36 dB.
Ist es ein Einzelhaus oder eine Wohnanlage? 20 Jahre alte Dosen sind den Anforderungen heutiger Netze nicht mehr gewachsen. Möchte nicht wissen, wie alt der Hausanschlussverstärker am Hausübergabepunkt dann ist. Es gibt doch diverse Frequenzbereiche/Kanäle, die früher für andere Dienste genutzt wurden und deshalb von Verstärkern und/oder Dosen rausgefiltert wurden. Das muss die Hausverwaltung modernisieren! Bei mir wurde in den 17 Jahren die ich hier wohne die Dose schon 2x unaufgefordert ausgetauscht.
Ich hatte kürzlich mal in Kodi bei der Wiedergabe eines Filmes mit etwas flauem Bild den Kontrast höhergeregelt. Nach dem Beenden der Wiedergabe und Rückkehr zu vdr stellte ich fest, dass die höhere Kontrasteinstellung immer noch aktiv war. Kodi hätte erst wieder beim nächsten Abspielen eines Films den Kontrast auf den Standardwert zurückgesetzt. Ich habe das zum Anlass genommen, dem Plugin mal Einstellungen für Helligkeit und Kontrast zu spendieren. Dabei werden die amlogic-internen Parameterwerte auf einen Regelbereich von 0 bis 100 umgesetzt. Also statt
// output contrast range is -127 to 127 with default of 0.
// output brightness range is -255 to 255 with default of 0.ist jeweils eine Einstellung zwischen 0 und 100 bei default-Wert 50 möglich.
Für Hue oder Saturation habe ich keine Einstellungsmöglichkeit gefunden. Der Kernel hat zwar
/sys/class/amvecm/saturation_hue
/sys/class/amvecm/saturation_hue_post
/sys/class/amvecm/saturation_hue_pre
/sys/class/video/saturationAber egal was man für Werte setzt, es ändert sich nichts am Bild. Da Kodi für amlogic auch keine Änderungsmöglichkeiten für Farbton und Sättigung in seinen Videoeinstellungen anbietet, gehe ich davon aus, dass es keine gibt.
Leider gibt es ein kleines Problem mit den bisher im Plugin enthaltenen (ungenutzten) Werten:
static int ConfigVideoBrightness; ///< config video brightness
static int ConfigVideoContrast = 100; ///< config video contrastDas hat zur Folge, dass jeder, der schon mal die Plugineinstellungen aufgerufen und mit ok verlassen hat, in seiner setup.conf bereits heute die Werte
softhdodroid.Brightness = 0
softhdodroid.Contrast = 100stehen hat. Danach richtet sich das um die Einstellungsmöglichkeit ergänzte Plugin nun natürlich und man erhält ein total unnatürlich wirkendes Bild. Da ich ahne, dass das zu etlichen Problemmeldungen führen würde, habe ich beim Einlesen der setup-Werte eine Prüfung eingebaut. Wenn Helligkeit 0 und und Kontrast 100 sind, wird unterstellt, dass das nicht gewollt sein kann und dass diese Kombination ein eindeutiges Indiz dafür ist, dass die Werte aus älteren Pluginversionen mit falschen default-Werten resultieren. Es werden dann stattdessen die Standardwerte = Mittelstellung (jeweils 50) gesetzt.
Ich denke nicht, dass man mit den Einstellungen die Bildqualität noch groß verbessern kann. Die Standardwerte sind bereits optimal, Nachjustierungen sollten m.E. am TV erfolgen. Die neuen Pluginparameter erlauben es aber nun, in Kodi für schlecht codierte Filme die Einstellungen bei Bedarf zu ändern. Bei Rückkehr zu vdr werden dann wieder die Plugin-Werte (in der Praxis wohl 50) gesetzt. Hat man in vdr einen abweichenden Wert konfiguriert, ist das auch kein Problem, denn Kodi setzt beim Abspielen eines Filmes den Wert immer auf Treiber-default zurück.
Getestet habe ich das mit S905X3 (Tanix TX3) und S922X (Odroid N2+) . Die Kernelparameter /sys/class/amvecm/contrast1 und /sys/class/amvecm/brightness1 werden auch von Kodi in AMLCodec.cpp verwandt und sollten somit auch bei anderen aml-Chipsätzen funktionieren, soweit diese von softhdodroid unterstützt werden.
Die Einträge die du gepostet hast sind vom OSD. Das läuft immer auf 1920x1080 und wird bei der Ausgabe auf die Screensize skaliert.
Würde ein OSD in 4k nicht besser aussehen? Hast Du es evtl. deswegen nicht implementiert, weil es derzeit (meines Wissens nach) gar keine Skins in UHD-Größe gibt?
Man müsste jetzt genauer analysieren, wie das satip-Plugin überhaupt den Kanalwechsel macht. Es ist ja aus Sicht von vdr ein DVB device. Der Ablauf wird von vdr wie folgt vorgegeben: Erstmal wird über die Priority sowie über Provides...-Funktionen geprüft, ob das device den gewünschten Kanal bereitstellen kann. Das kann das satip-Plugin m.E. nur aufgrund der ihm beim Start übergebenen Parameter prüfen. Eine Abfrage an den satip-Server findet da m.E. nicht jedesmal statt.
Das Beenden eines laufenden Streams sollte eigentlich in CloseDvr erfolgen. Das "Tunen" des neuen Kanals dann in SetChannelDevice. Danach wird dann mit OpenDvr der neue Stream geöffnet. Das basiert auf der DVB-Logik: Ein DVB device hat zwei unterschiedliche file descriptors, die unabhängig voneinander geöffnet und geschlossen werden können. Bei der Umsetzung für ein Plugin, das dem vdr analoge devices bereitstellt, bin ich deswegen halb verrückt geworden. Da gab es nämlich nur einen file descriptor. Wenn ich das in CloseDvr geschlossen habe, um den Stream zu beenden, lief der anschließende Versuch von SetChanneldevice, dort die Frequenz zu ändern, in einen Fehler. Und machmal ruft vdr OpenDvr zuerst auf (was dort automatisch zunächst einen CloseDvr auslöst...). Anfangs hatten wir deshalb darauf verzichtet, beim Kanalwechsel den Stream richtig zu beenden und einfach bei laufendem Stream den Kanalwechsel gemacht. Das führte mitunter zu genau solchen Problemen, dass im Buffer noch Reste vom alten Kanal waren. Später haben wir dann den eigentlichen Kanalwechsel in OpenDvr verlegt und dort eine Schleife eingebaut, die erstmal die Ausführung von CloseDvr abwartet.
Ich habe nur kurz in die Sourcen des satip-Plugins geschaut und überblicke die Ablaufsteuerung noch nicht. Aber dass in OpenDvr zunächst das propylaktische CloseDvr fehlt, wie es vdr in dvbdevice.c macht, halte ich für problematisch.
bool cSatipDevice::OpenDvr(void)
{
debug9("%s [device %u]", __PRETTY_FUNCTION__, deviceIndexM);
bytesDeliveredM = 0;
tsBufferM->Clear();
if (pTunerM)
pTunerM->Open();
isOpenDvrM = true;
return true;
}
void cSatipDevice::CloseDvr(void)
{
debug9("%s [device %u]", __PRETTY_FUNCTION__, deviceIndexM);
if (pTunerM)
pTunerM->Close();
isOpenDvrM = false;
}