Hallo,

es gibt im derzeitigen Enigma2 Probleme bei der Erstellung von EPG-basierten Timern. Versuche ich z.B. jetzt vor der Zeitumstellung einen Timer für einen EPG-Eintrag zu erstellen, welcher vor am 25.10 beginnt aber nach 00:00 endet, wird die Endzeit des Timers um -60 Minuten verändert. Z.B. bei der Navy CIS Wiederholung bei SAT.1. In der timers.xml ist die Endzeit dann in der Tat 60 Minuten früher. Auffällig ist dabei, dass wenn man beim editieren des Timers das Datum durch Drücken von links/rechts verändert, es zweimal den 25.10. gibt!
Vermutlich wird nicht korrekt erkannt, dass die Endzeit am 26.10 ist und nicht am 25.10, wo die Zeit ja vor der Zeitumstellung liegen würde (kann man seit einiger Zeit ja nicht mehr manuell ändern, ist auch ok). Verändert man nämlich die Endzeit auf Zeiten ab 02:00 funktioniert die Erkennung wieder.

Bye, schaumkeks

Zitat von Ghost

naja da konnte der Timer nicht gestartet werden... warum auch immer.. und dann versucht e2 verzweifelt (oder eher in diesem fall unlogisch) durch das stoppen des gerade laufenden services einen Tuner frei zu bekommen.

Der Timer ist in der Hinsicht einfach nicht intelligent genug um zu schauen, ob da nen playback läuft..dann macht es nämlich wenig sinn das zu stoppen.

Ich hab das eben im enigma2 git geändert. Ist dann in den morgigen experimental Images enthalten.

Aus dieser Änderung ergibt sich leider ein anderer Bug, hier mal das Szenario für eine Box mit 2 Sat-Tunern und der Einstellung "Aufnahmen haben Vorrang":

1. Tuner A durch Aufnahme aus Kanalbündel X belegt, Tuner B bis Zeitpunkt t durch Aufnahme aus Kanalbündel Y belegt, geplante Aufnahme aus Kanalbündel Z ab Zeitpunkt t
2. Daraus ergibt sich durch die Initialisierung der Aufnahme aus Z zum Zeitpunkt t - 20 s eine Überlappung
3. Wiedergabe einer Aufnahme vor dem Zeitpunkt t - 20 s starten
4. Seit diesem Fix wird nicht mehr versucht die Wiedergabe abzubrechen ("wenig Sinn")
5. Nun beenden wir kurz nach Zeitpunkt t die Wiedergabe, die Aufnahme aus Z konnte noch nicht gestartet werden, Aufnahme aus Y ist gerade beendet, wir belegen jetzt Tuner B mit einem Live Service nicht aus Z
6. Timer für Z versucht mit immer größer werdenden Timeout-Zeiten einen Tuner zu erhalten, versucht aber nie mehr zu zappen!

Mögliche Lösung: Test, ob gezappt werden soll nach jedem Timeout durchführen.

Bye, schaumkeks

Oops, noch nicht vollständig behoben. Bei diesem speziellen Szenario bleibt die Uhrzeit immer noch stehen:

1. Aufnahme aus Normalbetrieb (nicht aus Deep Standby) heraus gestartet, Aktion nach Aufnahme: In den Deep Standby
2. Box auf Standby schalten
3. Uhrzeit bleibt nach Herunterfahren durch Timer im Display stehen

Bye, schaumkeks

Hallo Tode,

leider hast du weder Empfangsart (DVB-S/T/C) noch eventuell betroffenen Skin oder betroffene Sender genannt...
Allgemein würde ich aber auf die nicht genannte Möglichkeit 4 tippen:

4) Einige Sender stellen nicht mehr Informationen zur Verfügung

Das kann bei einigen nicht sehr elegant in abgeschnittenen Worten resultieren. Bei anderen werden immerhin automatisch drei Punkte nach dem gekürzten Text angehängt (nicht verwechseln mit redaktionell hinzugefügten Punkten um nicht mehr Sendungsinhalt zu verraten).

Dass durchaus längere Texte in den DVB Service Informationen Platz haben (DVB SI) zeigt z.B. der EPG des ZDFdokukanal (zumindest über DVB-S Astra 19,2E), bei dem durchaus mehrfach gescrollt werden kann. Sollte in deinem Fall also Text einfach gekürzt sein, kannst du ja mal den Sender kontaktieren und darum bitten ausführliche Informationen bereitzustellen. Bei den Privaten wirst du da aber nicht weit kommen. Du sollst die Sendung ja schauen, egal ob es eine Wiederholung ist oder der Inhalt uninteressant klingt.

Bye, schaumkeks

Zitat von strichi

Gerade eben gab es einen tatsächlich informativen und sachlich korrekten Beitrag im ZDF bei WISO, der nun wirklich "jedem" eindringlich und leicht verständlich erklärt, was für ein schlechter Versuch HD+ wirklich ist, um uns Verbraucher hinter´s Licht zu führen.

Vor allem wurde die irreführende Bezeichnung "HD+" im Beitrag nicht ein einziges mal erwähnt.

Zitat von strichi

Also, wer sich jetzt noch HD+ andrehen lässt, der ist wirklich selber schuld ...

Naja, weiß denn der ZDF-WISO-Zuschauer jetzt auch, dass die tollen HD+ Receiver im Laden die im Beitrag genannte Verschlüsselungsschnittstelle CI+ mit sich bringen?

Bye, schaumkeks

Hallo,

ich habe hier eine DM7025 mit S+T Tuner und aktuellem CVS image (auch RC 22.08.2009) und suche Leute, die das folgende Problem bei DVB-T im Bereich Berlin/Potsdam bestätigen können:

Beim initialen Tunen auf einen DVB-T Sender des Kanals 33 (ZDF, 3sat, ZDFdokukanal/KiKa, ZDFinfokanal) im Raum Berlin/Potsdam beobachte ich schwere Probleme. Initial bedeutet, dass der DVB-T Tuner vorher nicht aktiv ist, also wenn vorher ein DVB-S Sender geschaut wurde oder die Box aus dem Deep Standby kommt. Der BER ist anfangs sehr hoch, die Nachricht "Tunen fehlgeschlagen" erscheint mehrmals, nach einiger Zeit ist das typische gequietsche vom Ton des Kanals zu hören und wenn man Glück hat ist nach einigen Minuten der Tune-Vorgang erfolgreich. Mit Sendern der anderen Kanäle tritt dieses Problem nicht auf. Wird von einem DVB-T Sender auf einen anderen geschaltet, egal ob gleicher Kanal oder nicht, gibt es keine Probleme. Als Work-Around ist also ein vorheriger Wechsel auf einen anderen Sender möglich. Fatal ist es allerdings bei Aufnahmen, deren Anfang dadurch defekt ist.

Wer hat dieses spezielle Problem (DVB-T, ZDF, Berlin/Potsdam) noch? Ich möchte ein Hardware-Problem ausschließen.

Werde bei Gelegenheit ältere Firmware testen und einen Enigma2 log hier hochladen.

Bye, schaumkeks

Check on your dreambox if all necessary processes are running with

root@dm7025plus2:~# ps ax | grep -e nfsd -e portmap -e mountd
20846 daemon      548 S   /usr/sbin/portmap 
20850 root            SW  [nfsd]
20851 root            SW  [nfsd]
20852 root            SW  [nfsd]
20853 root            SW  [nfsd]
20854 root            SW  [nfsd]
20855 root            SW  [nfsd]
20856 root            SW  [nfsd]
20857 root            SW  [nfsd]
20863 root       1052 S   /usr/sbin/mountd 
21083 root        568 S   grep -e nfsd -e portmap -e mountd

If portmap or mountd process are not running use nfsserver init script to restart:

root@dm7025plus2:~# /etc/init.d/nfsserver restart

If this gives errors, better stop first and then start by executing

root@dm7025plus2:~# /etc/init.d/nfsserver stop
root@dm7025plus2:~# /etc/init.d/nfsserver start

Danke für die bisherigen Bugfixes und weiter geht's mit dem RC vom 22.08.2009. Ich benutze englisches locale, deshalb die strings in Englisch.

* Bei Sofortaufnahmen "add recording (enter recording endtime)" auf Sendern ohne event info (z.B. Eurosport auf Astra 19,2°E) erscheint die irreführende Meldung "No event info found, recording indefinitely", ein Timer mit der korrekten Endzeit wird nämlich gesetzt. Weiterhin ist es möglich bei Sendern ohne event info eine Endzeit in der Vergangenheit zu setzen, dies resultiert in einem abgeschlossenen Timereintrag mit negativer Laufzeit und einer wenige Sekunden langen Aufnahme. Bei Sendern mit EPG wird stattdessen eine Aufnahme des aktuellen events ohne Nachlaufzeit geplant, was ok ist.

* Timer mit Status "about to start" (also ab 20 Sekunden vor Aufnahmestart) können noch deaktiviert ("Disable") werden, die Aufnahme startet aber trotzdem, was in der Timerliste dann natürlich nicht ersichtlich ist. Ist der Timer in der Liste an erster Stelle und die FB-Taste "Hoch/UP" wird nach Aufnahmestart mehrmals gedrückt, wechselt bei jedem Druck die Möglichkeit den Timer per "Enable" zu aktivieren (nicht bei wiederholenden Timern), was aber sowieso nicht funktioniert.

Ich konnte den folgenden Bug bezüglich Aufnahmen aus dem Deep-Standby in diesem RC aber auch noch im aktuellen CVS reproduzieren:
Verspätete oder keine Timeraufzeichnung nach Deepstandby

Bitte mal anschauen, Danke

Nach ausgiebigen Tests konnte ich die Problemschilderung verallgemeinern und den Bug reproduzieren. Der Bug beschränkt sich nämlich nicht auf DVB-T sondern tritt immer dann auf, wenn nach dem Bootvorgang ein Umschalten des gezeigten Programms notwendig ist, um die Aufnahme zu starten. Zum Reproduzieren beim Einsatz von Twin-Tunern, bei der Tuner B wie A konfiguriert ist, einfach mal Tuner B in den Einstellungen abschalten.

1. Timer auf einem Sender aus Kanalbündel X setzen, Verhalten nach der Aufnahme "automatisch" (oder auch "in den Deep Standy", nicht getestet)
2. Mit dem für die Aufnahme notwendigen Tuner auf einen Sender eines anderen Kanalbündels Y wechseln
3. Box in den Tiefschlaf versetzen

Was passiert:
1. Box bootet ca. 5 Minuten vor Aufnahmebeginn
2. Meldung "Zur Zeit sind Aufnahmen aktiv oder starten gleich..." erscheint, um nach Aufnahme automatisch abzuschalten
3. Sender des Kanalbündels Y wird gezeigt
4. Zum Zeitpunkt des Aufnahmebeginns muss mangels freiem Tuner für X zum Aufnahmesender gezappt werden aber...
5. Box geht in den Tiefschlaf
6. Box bootet wenig später wieder, Aufnahme beginnt verspätet

Bitte um Behebung, Danke

EDIT: Mit dem folgenden fix von ghost behoben:
http://git.opendreambox.org/?p…5b0068a986e83ec9bca515ddf

Bye, schaumkeks

Ghost hat jetzt den Schönheitsfehler behoben =)
http://git.opendreambox.org/?p…9d72c19b0a51db16240b2649d

Bye, schaumkeks

Hallo,

habe den RC mal mit einer DM7025+ im Flash getestet.

Allgemein:

* Auch in diesem RC bleibt der letzte Inhalt des LCD/OLED Displays, nach dem automatischen Herunterfahren durch einen Timer, sichtbar:
Uhrzeit bleibt im Display, wenn Box runtergefahren ist

* Soweit ich das sehe, hat auch die Lösung zu folgendem Problem noch nicht Einzug ins CVS gehalten:
Keine eindeutigen Dateinamen bei parallelen Aufnahmen von quasi-identischen Sendern (gleicher Sendername und gleicher Sendungstitel)

* Im Audio-Track Dialog ist wohl der Titel des Dialogs nicht gesetzt, deshalb steht dort der vermutliche Standard "Input", dort würde sich doch gut der darunter stehende Text "Select audio track" machen. Ist das Aufgabe des Skins?

Ich weiß, der MediaPlayer wird auch überschätzt Trotzdem hier ein paar Beobachtungen dazu:

* Abspielen einer Mono wav-Datei im MS PCM Format bringt keinen Ton hervor. kein Hinweis aber auch kein Hänger/Absturz.

playing 4097:0:0:0:0:0:0:0:0:0:/media/hdd/filetests/audio/Happyness.wav
SERVICEMP3 construct!
filename=/media/hdd/filetests/audio/Happyness.wav, containertype=0, is_video=0, is_streaming=0
starting pipeline
new service started! trying to download cuts!
download failed, no cuesheet interface
gst new pad! audio/x-raw-int
mime audio/x-raw-int
eServiceMP3::getCachedSubtitle
[__evUpdatedInfo] title 0 of 0 ()
Gstreamer error: Could not open device for playback in mono mode. (13) from alsa-output
Gstreamer error: Could not get/set settings from/on resource. (13) from alsa-output
Gstreamer error: Internal data flow error. (1) from file-source
error in tag parsing, linking mp3parse directly to file-sink, bypassing id3demux...


(enigma2:5247): GStreamer-CRITICAL **: gst_element_unlink: assertion `GST_IS_ELEMENT (dest)' failed


(enigma2:5247): GStreamer-CRITICAL **: gst_element_link_pads_filtered: assertion `GST_IS_ELEMENT (dest)' failed
gst new pad! audio/x-raw-int
[__evUpdatedInfo] title 0 of 0 ()

* Abspielen einer wav-Datei im MS ADPCM Format führt zur Message "GStreamer plugin Microsoft ADPCM decoder not available!" und dann drehen sich die Rädchen bis ins unendliche.

playing 4097:0:0:0:0:0:0:0:0:0:/media/hdd/filetests/audio/Max_Payne_Theme.wav
SERVICEMP3 construct!
filename=/media/hdd/filetests/audio/Max_Payne_Theme.wav, containertype=0, is_video=0, is_streaming=0
starting pipeline
getBouquet failed.. no path given!
getBouquet failed.. no path given!
new service started! trying to download cuts!
download failed, no cuesheet interface
unknown type: audio/x-adpcm - this can't be decoded.
[__evPluginError] 
warning, skin is missing element Title in <class 'Screens.SimpleSummary.SimpleSummary'>
mime audio/x-adpcm
eServiceMP3::getCachedSubtitle
[__evUpdatedInfo] title 0 of 0 ()
Gstreamer error: Internal data flow error. (1) from file-source
error in tag parsing, linking mp3parse directly to file-sink, bypassing id3demux...


(enigma2:6455): GStreamer-CRITICAL **: gst_element_unlink: assertion `GST_IS_ELEMENT (dest)' failed


(enigma2:6455): GStreamer-CRITICAL **: gst_element_link_pads_filtered: assertion `GST_IS_ELEMENT (dest)' failed
unknown type: audio/x-adpcm - this can't be decoded.
[__evPluginError] GStreamer plugin Microsoft ADPCM decoder not available!

* Abpsielen einer m4a (AAC) Datei führt zu einer Message ohne Inhalt und dann drehen die Rädchen bis ins unendliche.

playing 4097:0:0:0:0:0:0:0:0:0:/media/hdd/filetests/audio/commie078-desert_planet-attack_of_the_mutant_mirages.m4a
SERVICEMP3 construct!
filename=/media/hdd/filetests/audio/commie078-desert_planet-attack_of_the_mutant_mirages.m4a, containertype=5, is_video=0, is_streaming=0
starting pipeline
getBouquet failed.. no path given!
getBouquet failed.. no path given!
new service started! trying to download cuts!
download failed, no cuesheet interface
unknown type: video/quicktime - this can't be decoded.
[__evPluginError] 
warning, skin is missing element Title in <class 'Screens.SimpleSummary.SimpleSummary'>
Gstreamer error: A Quicktime demuxer plugin is required to play this stream, but not installed. (6) from decoder
Gstreamer error: Internal data flow error. (1) from file-source
error in tag parsing, linking mp3parse directly to file-sink, bypassing id3demux...


(enigma2:5247): GStreamer-CRITICAL **: gst_element_unlink: assertion `GST_IS_ELEMENT (dest)' failed


(enigma2:5247): GStreamer-CRITICAL **: gst_element_link_pads_filtered: assertion `GST_IS_ELEMENT (dest)' failed
unknown type: video/quicktime - this can't be decoded.
[__evPluginError]

Kann bitte jemand den Fix noch ins CVS übernehmen?
Danke.

EDIT: Jetzt im CVS
http://git.opendreambox.org/?p…6e15d0fe5dd77fcfc624084c1

Vermutlich mit der Änderung
https://lists.elitedvb.net/pip…-cvs/2009-May/005753.html
gibt es keinen Absturz mehr in diesem Zustand (kein Bild und Ton) beim Druck einer Sprungtaste, sodass man wieder zum Abspielzustand kommt.

Danke

Im Live-Modus scheint es wieder zu funktionieren, aber es gibt Probleme bei Aufnahmen. So habe ich eine Aufnahme auf rbb brandenburg für das Regionalfenster mit Vor- und Nachhlaufzeit programmiert 19:25-20:10. Die Video-PID wechselt immer ca. 19:26 zu Beginn des Wetterberichts. Die Aufnahme bricht an dieser Stelle ab. rbb berlin behält die ganztägige Video-PID, dort müsste es also funktionieren.

Keine Ahnung, ob das bereits vor der oben angegebenen Änderung im cvs so war oder eine Regression ist.

Ich benutze ein aktuelles OoZooN CVS auf einer DM 7025+ 2xSat und habe regelmäßig sehr lange Aufnahmen von ca. 9 Stunden (keine Ahnung ob die enorme Länge relevant ist, fragt nicht). Beim Durchschauen der Aufnahmen verwende ich häufig Sprünge sowohl vor als auch zurück mittels der Zifferntasten (Sprungweite auf Standardwerten). Seit einiger Zeit (ich glaube erst seit Mai) kommt es sporadisch vor, dass nach einem Sprung das Bild schwarz und der Ton wegbleibt. Aus Reflex wird dann meist nochmal versucht zu springen, was dann zum Buntscreen führt. Wird jemand aus dem crashlog schlau?

Zitat von ritzMo

schaumkeks: könntest du zum testen mal deine Tools.Directories.getRecordingFilename (/usr/lib/enigma2/python/Tools/Directories.py) anpassen? In Z. 188 folgende Anweisung einfügen:

Code

open(path + ".ts", 'w').close()

Danke ritzMo, das scheint zu funktionieren. Die zweite Aufnahme landet jetzt separat mit suffix _001 auf der Festplatte.

Einige Sender sind ja mit selbem Namen und gleichem EPG durch verschiedene Empfangsarten verfügbar, z.B. anderer Satellit oder DVB-t oder DVB-c.

Szenario:
Aufnahme einer Sendung von zwei verschiedenen Quellen DVB-s und DVB-t (z.B. ZDF von Astra 19,2E und DVB-t Berlin/Potsdam) um die Wahrscheinlichkeit einer defekten Aufnahme durch Ausfälle zu vermeiden. Es sind keine Alternativen definiert. Die Timer werden über den EPG programmiert und besitzen identische Startzeit, Sendername und Sendungstitel.

derzeitiges Verhalten:
Beide Timer gehen "gleichzeitig" in den Aufnahmemodus, die Dateinamen sind jedoch durch Erzeugung aus den oben angegeben Informationen identisch! Auf der Festplatte landet nur eine Aufnahme (keine Ahnung welche)!

gewünschtes Verhalten:
Erzeugung von identischen eindeutigen Dateinamen (Indexnummern, wie in anderen Fällen verwendet) um solche separaten Aufnahmen zu ermöglichen.

Umgebung:
DM7025ST mit aktuellem Enigma2 CVS

Mit aktuellem CVS-Image gibt es ein merkwürdiges Verhalten bei der Änderung der Startzeit von Timern:

1. Wird die Startzeit eines Timers vorgezogen (liegt aber immer noch in der Zukunft), startet die Aufnahme trotzdem zur alten Startzeit.

2. Wird die Startzeit eines Timers nach "hinten" gelegt, wird die Aufnahme zur alten Startzeit initialisiert und bis zur neu gesetzten Startzeit befindet sich der Timereintrag im Zustand "about to start".

3. Ähnliches gilt auch für End-Zeiten von Timern

Der Timereintrag nimmt jeweils die neuen Zeiten an, jedoch werden diese bei der Ausführung ignoriert und die alten Daten verwendet. Auffällig ist, das in der log der Timer auch keine Änderungen protokolliert sind.

Sehr ungünstig bei den teilweise sehr dynamischen Sendeterminen besonders nach der Primetime

Bye, schaumkeks

Ja, auch eine Sache dir mir öfter passiert.

Einziger mir bekannter Workaround ist das Beenden (Stop) der Wiedergabe und anschließendes Starten. Das direkte Weiterschauen an der Stelle ist dann aber meist nicht möglich, trotz Frage, ob an der letzten Stelle weiter abgespielt werden soll, wird bei 0:00 gestartet. ok, merkt man sich halt die Stelle und springt mit lang gedrückter blauer Taste

Bye, schaumkeks