Beiträge von dj_macgyver

eine sache, auf die ich gerade mehr oder weniger freiwillig gekommen bin: in der readme zum plugin (zumindest in der 0.0.009er version, vielleicht hat das ja in den neuen pre-versionen schon jemand gefixt) fehlt "bc" bei den requirements.

ohne bc kann die getCutSize()-funktion in der vdrburn.sh beim markieren einer aufnahme deren grösse nicht ermitteln, was wiederum dazu führt dass das burn-plugin denkt, dass keine dateien im aufnahmeverzeichnis vorhanden wären. auszug aus dem syslog:

Mar 29 18:59:36 vdr vdr[19331]: BURN: No datafiles in /video/Terminator_III_-_Rebellion_der_Maschinen/2006-03-12.20.14.50.99.rec (this shouldn't happen!)

nach der installation von bc ist die anzeige wieder in ordnung.

gruzz
macgyver

hmmmm ich hatte mit vdr + streamdev-server ähnliche probleme mit mplayer als client... die artefakte kann ich jetzt im moment nicht reproduzieren (kann mich aber erinnern, das auch mal gehabt zu haben) aber ruckeln kann ich z.b. auf rtl nachvollziehen... ich hab das problem umgangen, indem ich immer -cache 2048 mit angebe.

wie sich das allerdings auf den windows media player übertragen lässt kann ich leider nicht sagen... vielleicht tut's ja auch ein anderer client (vlc oder mplayer für windows? müsste doch was geben...)

ausserdem verwende ich für tv-kanäle grundsätzlich TS (für radiokanäle hingegen ES) in der URL. ich glaub das half gegen die artefakte.

sorry für die etwas ungenauen auskünfte, aber ich habe bisher nur experimentiert damit

Zitat

Original von AlliedBlue
Tut mir ja leid, dass es nicht ins System passt Bisher hatte ich auch keinen Absturz mehr (EPG Scan ist natürlich jetzt aus). Wer weiß, vielleicht ist es auch bei mir ein anderes Problem als bei euch...

Habe mal auf France 5 geschaltet: kein Bild weil verschlüsselt und auch nur 2 EPG Einträge, aber kein Absturz.

Gruß
Sven

war kein vorwurf

aber bisher hatte von uns noch niemand das problem auf astra, nur hotbird...

mittlerweile gibt's einen patch, vergleiche hier: http://www.vdr-portal.de/board/thread.php?threadid=45965&sid=

seitdem läuft auch mein epg-scan wieder, keine probleme bisher. vielleicht lässt sich dein problem ja trotzdem damit bereinigen

gruss
mac

p.s. eigentlich könnte man diesen thread hier auch mit verweis auf den anderen zumachen, wie ich das sehe is das dort soweit gelöst... oder wie wird das hier im forum gehandhabt?

Zitat

Original von Django
HI,

hier nun der offizielle patch von kls (aus der Mailingliste]:

auch hier noch einmal ein dankeschön (wenn auch indirekt)

der patch liess sich auch auf meinen 1.3.32er vdr ohne probleme anwenden, und die franzosen verursachen keinen absturz mehr:

Zitat

Original von UFO
Also bei mir müßte der EPG-Scan jetzt schon wieder mehrere Male problemlos durchgelaufen sein. Scheint alles ok.

auch ich konnte nach einspielen des patches wieder ohne probleme mit beiden karten über mehrere stunden fernsehen etc. also ist das ganze zumindest vorübergehend als lösung akzeptabel

Zitat

Original von UFO
Liegt wohl an irgendeinem Descriptor. Ob der Fehler beim Sender oder in VDR liegt, kann ich nicht sagen. Bin noch nicht dazu gekommen, so richtig in die Tiefen der libsi einzutauchen.

Anyway, ein paar zusätzlich Plausibilitätschecks an der richtigen Stelle dürften sich positiv auf die Robustheit auswirken. (Die Stelle, die ich gepatcht habe, ist vermutlich nicht optimal.)

CU
Oliver

seh ich ähnlich... nur dass meine programmierkenntnisse in c/c++ wohl nicht ausreichen dafür ich scheitere ja meistens schon auf der suche nach dem problem...

trotzdem, danke nochmal für den patch

Zitat

Original von AlliedBlue
(...) Im übrigen nutze ich NUR Astra 19.2. EPG Scan ist bei mir jetzt aus, und bisher gings wohl, zumindest habe ich bisher keinen Absturz mehr bemerkt. (...)

das passt jetzt wieder nicht so ganz ins system, eigentlich haben wir gestern einen transponder auf hotbird als fehlerquelle ausgemacht...

da die fanzosen allerdings auch über astra senden, könnte ich mir durchaus vorstellen, dass die selben daten dort mit verzögerung auch eingespielt wurden / werden...

du kannst ja mal versuchen, auf einen der Kanäle "FRANCE 3" oder "FRANCE 5" zu schalten (mehr fallen mir jetzt aus dem stegreif nicht ein). wenn dein vdr in diesem moment abstürzt, wäre das eine bestätigung für meine vermutung...

mit eingespieltem patch kann ich ohne probleme auf den kanal "FRANCE 3" schalten, kein absturz bei mir... ich bekomme kein bild, aber der kanal ist ja auch verschlüsselt... dafür hab ich aber sogar 2 epg-einträge... muss ich erst wieder den epg-scan abwarten, um sicher zu sein?

Zitat

Original von UFO
Und ja, der FRANCE-Transponder auf Hotbird scheint tatsächlich für die Abstürze verantwortlich zu sein.

ob's an diesem komischen h264-kanal ("FLUX H264 TPS") liegt?

Zitat

Original von I30R6
hmm .. bei euch ist es nur gekillt bei mir ist es immer nen Neustart und der Log spuckt nix vernünftiges aus.

ich tippe mal auf ein runvdr-script, oder?

Zitat

Original von mini
Vielleicht kann das ja jemand verifizieren.

Marcus

verifizieren kann ich's nicht mehr, jetzt nachdem ich den obigen patch eingespielt habe. aber ich sehe jetzt beim schalten auf einen der kanäle auf 10834v den folgenden block:

assign size oops ffffffff
assign size oops ffffffff
assign size oops ffffffff
assign size oops ffffffff

ich denke, das sagt auch etwas aus.

so... hab jetzt vorhin nochmal getestet und eine aufnahme laufen lassen im single-card betrieb. ist bei genau 18:30 stehengeblieben (das osd zeigt das jetzt noch an ;)) und der letzte eintrag im syslog war wieder:

changing transponder data of channel 2703 from S13.0E:11283:v:27500:3 to S13.0E:11280:v:27500:3

allerdings liegen zwischen dem eintrag und dem tatsächlichen ende ca. 1-2 minuten, zeit genug um noch einige andere sender abzuscannen imo.

den patch werd ich gleich mal einspielen... sieht auf den ersten blick vernünftig aus. danke

um das ganze problem mal weiter einzukreisen... wer von den betroffenen empfängt welche satelliten?

soweit ich das sehe kommen als fehlerquelle derzeit transponder auf astra1 und eutelsat in frage.

Zitat

Original von Django
Ja mei, so samma hoid amoi, oda?

Zitat

Original von Django
Das Gezeter und Gemecker war schon arg, bis ich ihr dann meinen Developer-VDR (http://vdr-portal.de/board/thr…?postid=139047#post139047) ins Wohnzimmer gestellt hab'. Ist ja auch verständlich, wenn die geliebte Sendung nicht angekcukt werden kann.

ja die situation kann ich mir fast vorstellen... soweit bin ich mit meinen basteleien aber noch nicht... mein vdr is derzeit noch eine richtige baustelle (front offen, alles mit klebeband zusammengehalten...) da bist du mir um längen voraus

Zitat

Original von Django
Kannst Du mal den channels.conf Eintrag für diesen Kanal posten, damit ich den Kanal hier auch finde. Zur Not schalte ich den Transponderupdate aus und werf' den Eintrag einfach mal aus meiner channels.conf. Dann sollte der Absturz ja weg sein, oder?

das wäre diese hier:

test;CYFRA +:11280:vC34:S13.0E:27500:0:111=pol:0:100:13030:318:400:0

aber wie ich oben schon geschrieben habe, ich glaube nicht, dass es die zeile ist, da ich den kanal ohne probleme einschalten kann. es wäre praktisch, dem vdr beim epg scan zuschaunen zu können, sprich: mitlesen zu können, welchen transponder er gerade scannt. dann könnte man's gezielt eingrenzen...

Zitat

Original von Django
Da fragst Du gerade den richtigen. Soviel Ahnung hab' ich nun auch wiederum nicht.

ich leider auch (noch?) nicht... mal schaun was da noch kommt...

Zitat

Original von Django
Deaktivieren, sollte IMHO z.B. durch Hochsetzten des Timeouts gehen, also z.B.: EPGScanTimeout = 0 siehe http://www.vdr-wiki.de/wiki/index.php/Benutzerhandbuch#EPG

ah danke ich brauch das vdr-handbuch mal in gedruckter form, so dass es zur geeigneten zeit auf meinen kopf drauffallen kann

Zitat

Original von Django
Pfiade,
BC

P.S.: Aktuelle höchste Channelnummer: 3863

bei mir: 5177 aber ich sehe wiederholt, dass da viele einträge nicht stimmen können und durch den autmatischen transponderscan in verbindung mit schaltfehlern der diseqc-schalter entstanden sein müssen...

Zitat

Original von Django
Guggst Du hier => http://vdr-portal.de/board/thread.php?sid=&postid=426435

Es scheint wohl ein generelles Problem zu bestehen.

danke für den link. um ehrlich zu sein, beruhigt mich das sogar, da ich jetzt zumindest weiss, dass es nicht die hardware ist, die sperenzchen macht... jetzt heisst's problem einkreisen und mit allen waffen bekämpfen

pfiade,
mac

Zitat

Original von Django
Habedieehre,

gaaaanz habedieehre

da wahnsinn, no a bayer do legst di nieda

Zitat

Original von Django
Also, bei mir hier ging gestern Abend (verständlicherweise) der WAF von 99,999% schlagartig runter auf 2%.

jetzt musst ich doch glatt googlen was WAF is... aber hab's verstanden ich hoffe es ging ohne blessuren ab

Zitat

Original von Django
Das da ev. mit den EPG-Daten was nicht stimmt, meinte auch schon randy heute Mittag, kurz vor den beiden dicken Schnitzeln.
Ich hab' neben Astra noch den Eutelsat angepeilt. Aktuell steht der letzte Kanal in meiner channels.conf als Channel Nummero 3409 drinnen.

mir is die 2703 nur aufgefallen, weil der jetzt schon mehrere male im letzten eintrag im system log war (auch erst durch nachschauen rausgefunden... wär mir so jetzt nicht aufgefallen)

aber offensichtlich ist es nicht der kanal mit den fehlerhaften / unverständlichen daten, denn ich kann den ohne probleme anschalten (dabei müssten ja auch die epg-daten eingelesen werden)... wie geht denn der vdr beim epg-scan vor?

die nächste zu klärende frage wäre dann wohl, handelt es sich um korrupte / fehlerhafte daten vom provider oder sind die daten an sich korrekt, lösen aber im vdr eine unbeabsichtigte reaktion aus? aber ich glaube dazu braucht's 'nen spezialisten...

Zitat

Original von Django
Das hast Du richtig gesehen, mein TecVDR läuft derzeit nur mit einer Karte. Solange ich TV kucke alles kein Problem, denn dann ist beim 1-Kartenbetrieb keine Zeit für 'nen EPG-Scan. Schaue ich dagegen eine DVD an, dann rotzt der gute nach ca. 15 Minuten weg, weil dann ev. wieder ein Scan im Hintergrund laufen kann - so meine Vermutung.

Pfiade,
BC

ich hab leider (noch) kein dvd-laufwerk im xS drin, aber alternativ müsste ja das abspielen einer aufnahme von festplatte die selben folgen haben. werd's nachher testen. im moment läuft er mit einer karte recht dankbar und stabil...

wie kann ich denn den epg-scan deaktivieren? ich hab hier nur einstellungen für den timeout, bugfix level und linger time... keine möglichkeit zum deaktivieren?

Zitat

Original von Oxygen
Ich habe den "Spass" auch seit gestern an meinen beiden VDR (unterschiedliche Kernel- und VDR-Versionen). Schalte mal den EPG-Scan aus. Bisher hatte ich noch keinen weiteren Neustart. Mich würde echt mal interessieren, was diesen Mist verursacht. In den Logs steht absolut nichts.

noch einer... erhärtet den verdacht auf korrupte daten, würd ich sagen...

ich sehe auch an den sigs, dass keiner von euch 'ne skystar verwendet... also vielleicht doch was anderes?

Zitat

Original von Django
HI,

also langsam wirds mir unheimlich.

Das selbige Phänomen habe ich hier auch, Nach 15 - 20 Minuten stirbt plötzlich der VDR ohne erkennbaren Grund. Das einzige was ich bisher Dank des kleinen Hausbesuchs vom VDR-LINUX-HALBGOTT randy herausbekommen habe ist: http://vdr-portal.de/board/thr…?postid=426272#post426272

Welche VDR Version hast Du denn am laufen?

cu,
Django

Alles anzeigen

unheimlich... ja das ist es wohl... wie lange hast du das problem? die posts in dem link sind alle von heute... sind das vielleicht korrupte daten auf einem transponder die seit gestern runterkommen? bei mir is die auswahl allerdings ziemlich gross, da ich astra1, astra2 (incl. 2d), hotbird und eurobird angeschlossen hab... meine channels.conf geht derzeit auf 5000 einträge zu...

aufgefallen is mir in dem zusammenhang kanal 2703... das wäre ein radio-sender namens "test" auf hotbird 11280 v mit apid 111, verschlüsselt...

ich lasse gerade den vdr mit -D 1 laufen, damit wird nur noch die ff-karte verwendet. aber selbst das wäre zunächst kein beweis, dass die skystar schuld ist, da ja jetzt auch der epg-scan im hintergrund nicht mehr läuft (der ja im falle von korrupten daten auch auslöser des problems sein könnte)

ich müsste also 6h warten bis der idle-timer abgelaufen ist, und die primär-karte für den epg-scan verwendet wird...

Hallo an die Runde!

Ich hab seit gestern ein kleines Problem mit meinem neuen vdr: Die Software wird urplötzlich, ohne nachvollziehbaren Grund, beendet - und zwar auf die harte Weise (vermutlich SIGKILL) da im syslog nicht der geringste Hinweis zu finden ist. Die üblichen Einträge über das Entladen von plugins etc. fehlen komplett, die vdr-Prozesse sind verschwunden. Das ganze passiert in unregelmässigen Abständen (irgendwann zwischen 15 minuten bis 2 stunden hatte ich bisher). Wenn ich den VDR auf der Konsole starte erhalte ich auf der Kommandozeile als letzte (und einzig auffällige Zeile) lediglich ein "Killed".

Das ganze Problem trat gestern zum ersten mal auf, leider wiederholt es sich scheinbar immer wieder. Laufende Aufnahmen gehen natürlich dadurch kaputt

Am System hab ich bis zum Auftreten des Problems nichts verändert, aber um's in den griff zu bekommen hab ich erstmal versucht, meinen Kernel von 2.6.13.4 auf 2.6.15.4 zu aktualisieren (ohne Erfolg, dafür ging erstmal mein LIRC nicht mehr... aber das hab ich im griff)

Konfiguration:
Fujitsu Siemens xS PIII 800 MHz 192MB RAM
1 x Technotrend Premium S2300 mit RGB-mod (dvbshop)
1 x Technisat Skystar2 2.6D
LIRC-Selbstbau-Receiver an COM2
2farbige LED an COM1 in Kombination mit einem modifizierten serial-plugin (nein an der Modifikation liegt's leider nicht, auch ohne das serial-plugin tritt das problem auf...)
Derzeit Anbindung des /video-Verzeichnisses über Samba (200GB die ich mangels SATA nicht in den xS einbauen kann; neue Platte ist bestellt)
www.linuxfromscratch.org mit Kernel 2.6.15.4, der treiber für die s2300 ist als modul kompiliert, der skystar-treiber ist im kernel integriert
keine speziellen dvb-treiber (d.h. es sind die standard-treiber aus den kernel-sources in betrieb)
vdr 1.3.32 mit etlichen Plugins

wie bereits erwähnt, keine einträge in /var/log/messages, und auf der Konsole lediglich ein "Killed"...

meine Vermutung geht in richtung der skystar2 - ich hatte mit dieser karte bereits ein ähnliches phänomen in einem anderen rechner und skynet... dort trat das problem allerdings von anfang an auf. ich möchte demnächst noch testen, ob das problem auch auftritt, wenn ich den vdr mit der entsprechenden -D option auf die s2300 beschränke.

allerdings lief die skystar zuvor bereits ca. 2 monate lang problemlos in dem besagten rechner für einen vdr mit xine-plugin... und auch seit ich sie in den xS umgebaut habe (ca. 1 monat her) hatte ich keine probleme, erst seit gestern.

hatte schonmal jemand ähnliche probleme und einen lösungsansatz? kann mir vielleicht jemand 'nen tipp geben, wie ich das problem debugen kann? sprich, wie bekomm ich raus, was den vdr killt, und warum?

vielen dank für alle tips