Beiträge von herrdeh

Das hab ich eh gleich als erstes gemacht, nachdem die Kanalsuche einmal durch war. Man will ja nicht unnötige Kanäle mühsam rauslöschen und dann werden sie einem automatisch wieder reingemüllt...

Moinsen, das Dings läuft eh seit Jahren mit Hub&externem NT. Der Governor war auf "powersave", hab ihn mal auf "performance" geändert, das hat aber nix verbessert, der Absturz nach Pause kommt genauso.

Ein Kollege aus dem MLD-Forum meinte, das könnte ein bekanntes Raspian-Kernelproblem sein, das bei früheren Kernelversionen nicht auftrat:

https://github.com/raspberrypi/linux/issues/3631

Komischerweise stabilisiert sich das Verhalten des Systems, wenn man länger nicht an der Kanalliste bastelt. Meine ist inzwischen halbwegs o.k., und jetzt läuft der VDR auch ziemlich stabil. Seltsamdas...

Grüße vom Wolf

Moinsen,

hier kommen jetzt noch zwei logs.

Log1 ist nach einem Absturz aufgezeichnet, bei dem ich den VDR mit der FB bedient habe, nicht besonderes, Wiedergabe, Kanäle schalten, Aufnahmen löschen oder so Zeugs.

Log2 ist ohne Bedienaktivität entstanden; das ist einer von diesen typischen nervigen Abstürzen, während der VDR einfach läuft. Einen halben Tag vorher habe ich ein paar Handvoll Bezahlsender über OSD gelöscht. Das scheint etwas zu sein, was die Absturzneigung deutlich erhöht...

Grüße vom Wolf

Moinsen, Dank für die intensive Befassung mit diesem Quatschzeugs...

In der letzten Woche sind die Abstürze viel weniger geworden, man könnte den Eindruck gewinnen, daß sich das System ein bißchen an die neue Kanalliste "gewöhnen" muß. Hab heute nochmal ca. 10 Einträge rausgeworfen (OSD), mal sehen, ob er demnächst wieder einen Absturz produziert.

Dr. Seltsam :

Ich hab alle Methoden zum Umsortieren durchprobiert: gedit über nfs, das OSD, den online-Editor des webif, nano über die Konsole. Zuletzt nur noch ganz brav zu Fuß über das OSD. Stets habe ich nur Einträge gelöscht oder umsortiert.

FireFly :

Daß es mit den Timern zu tun hat, glaube ich eher nicht, weil das Problem genauso bei einem frisch aufgesetzten System, wo es noch gar keine Timer gibt, auftritt. Das USB-Dings hat den Aufdruck "Terratec Cinergy H5" und meldet

em28xx 1-1.3:1.0: DVB interface 0 found: isoc

em28xx 1-1.3:1.0: Binding DVB extension

dvbdev: DVB: registering new adapter (1-1.3:1.0)

em28xx 1-1.3:1.0: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)...

dvbdev: dvb_create_media_entity: media entity 'DRXK DVB-C DVB-T' registered.

em28xx 1-1.3:1.0: DVB extension successfully initialized

Mit einem anderen USB-Adapter tritt allerdings das gleiche Problem auf.

Loglevel 3 hab ich eingerichtet, jetzt muß ich erst mal wieder auf einen passenden Absturz warten.

Es gibt noch einen anderen Absturz, der ist einfach zu reproduzieren:

* Wiedergabe einer Aufnahme starten

* Pause drücken

* Wiedergabe beenden (FB blau)

Dazu ein Satz logs (level 3) anbei, ob die beiden miteinander zu tun haben, weiß ich nicht. Habe den letzeren auch im MLD-Forum gemeldet.

Dank für Euere Mühe und einen schönen Sonntag.

Grüße vom Wolf

Moinsen,

ich weiß, daß die folgende Fehlerbeschreibung völlig idiotisch klingt, aber ich hab Monate dranrumgetestet und komme immer zum gleichen Resultat. Leider wissen die geschätzten Kollegen aus de MLD-Forum auch nicht mehr weiter...

Hab eine MLD 5.5 auf einem RPI4 laufen, mit USB-DVB-C. An diesem DVB-C-Anschluß war der VDR schon immer ein gewisses Problem, die letzte, die gut lief, war MLD 5.1 auf einem RPi3, alles danach hat immer fürchterlich geruckelt. Eventuell hängt das mit dem etwas berüchtigen Anbieter "Pyur" - vormals Telecolumbus - zusammen.

Die 5.5 geht nun einigermaßen ordentlich - nur wenn ich die Kanalliste irgendwie bearbeite (Einträge lösche, verschiebe), wird VDR instabil und stürzt in der Regel nach einigen Stunden ab. Er versucht dann neuzustarten, es kommt dann meist alle 1-2 Minuten ein paar Sekunden Ton - und dann isser wieder tot. Irgendwann hängt sich dann auch die Linux-Gundlage auf. Mit der Kanalliste, die sich das System selbst sucht, läuft er Tage durch.

Ja, klingt dämlich. Aber ich komme zu keiner anderen Beobachtung.

Ich hab x mal neu installiert, alle Plugins weggelassen und was weiß ich. Der entscheidende Faktor war immer die Kanalliste. Wenn ich nur 2-3 Einträge ändere, geht es besser - aber große Eingriffe in die Liste führen ins Desaster...

Blöddas - aber vielleicht hat jemand eine gute Idee. Anbei zwei MLD-Logs.

Grüße vom Wolf

Die c't schreibt "2W" Leerlauf - dazu kommt noch der Hub, da sind meine 4,5W ohne DVB-Adapter wohl nicht ganz unsinnig.

@ Argus

Zitat

wobei ganz auf null Watt wirst du das Ganze nicht bekommen, irgendwas Schaltauslösendes muss ja unter Dampf gehalten werden, also quasi dafür doch mindestens ein Netzteil.

Meine Idee war, das Anziehen des Relais über die Uhrenbatterie zu machen, die dann sofort vom Netzteil abgelöst wird, wenn die 5V da sind. Evt müßte man einen Akku oder einen Kondensator für die Uhr nehmen, sollte das kurze Anziehen zu viel Strom brauchen, oder Probleme entstehen, wenn eine Primärzelle quasi "geladen" wird.

Moinsen, und Dank für die zahlreichen Zuschriften..

@ mini 73

Zitat

Hast du schon mal den Stromspar-Patch von der vdr-Mailingliste probiert oder (wenn deine Distri das hergibt) mal den dynamite-Patch inkl. Idle-Mode mit dem dynamite-Plugin? Das deaktiviert den DVB-Tuner nach einer Weile Nicht-Gebrauch.

Ich hab's im Hauptartikel noch mal klargestellt: selbst wenn ich den Raspi ohne DVB-Adapter starte, braucht das System immer noch 4,5W. Und mit einer Software-Lösung bin ich nie auch nur in die Nähe davon gekommen.

@ Argus
http://www.raspberry-pi-geek.d…gesteuert-starten-per-RTC
Schöne Lösung - schaltet aber auf der 5V-Seite, was immer noch 1-2W Leerlaufstromaufnahme bedeutet. Und die möchte ich nicht haben, wenn ich den ganzen Aufwand schon treibe. - Deswegen auch ein Relais - MOSFets vielleicht eher nicht für 230V... (-;

Dank für den Hinweis auf die schon in diesem Bereich aktiven Kollegen - werd' sie mal anschreiben, sofern sie sich nicht selbst melden.

@ MReimer
Wie genau das Ding wirklich mißt, weiß ich nicht. Da ich aber bei "poweroff" (nur Raspi ohne Hub) auf 0,4W komme (der EM600 kann also auch einen sehr niedrigen Verbrauch erfassen), scheint es mir halbwegs plausibel.

Natürlich ist der Raspi im Normalbetrieb kein Stromfresser. Erschreckt hat mich allerdings der Stromverbrauch im Leerlauf - 7W x 22h x 365d = ca. 56 kWh - das ist immerhin Strom für ca. 17€, bei dem außer Wärme gar nichts produziert wird.

Mein System:
Mein RP3 hat ein minidvblinux (MLD) 5.1 drauf, er bespielt über den Analogausgang einen alten Röhrenfernseher. Am Raspi-USB direkt hängt ein Hauppauge DVB-C-USB-Adapter sowie ein Phillips USB-MediaCenter-IR-Empfänger, und über einen aktiven USB-Hub eine 250GB-2,5'-Platte.
Das System läuft als "ganz normaler VDR" - nimmt also Fernsehsendungen auf, die ich dann irgendwann ansehe. - Bei mir läuft das System im Tagesdurchschnitt vielleicht 1-2h - sonst hat er nichts zu tun.

Den Stromverbrauch messe ich auf der 230V-Seite mit einem EM600 - das sind keine Präzessionsmessungen, dürfte aber zumindest die Relationen einigermaßen plausibel abbilden.

Stromverbräuche:
Raspi-System
ausgeschaltet ("poweroff"), Raspi&Hub am Netz: 1,5W
suspend-soft, Platte steht: 7W
(suspend-soft, Platte steht, DVB-Adapter rausgezogen) - in der Praxis nicht realisierbar: (4,7W) - das ist der Grund, warum Software-Lösungen wohl nicht zielführend sind, denn weniger Strom als "rausgezogen" kann der DVB-Adapter ja nicht verbrauchen)
Leerlauf: 7,5W
Aufnahme / Wiedergabe 8,5W

Jahresverbrauch Raspi-System:
Leerlauf - 7W x 22h x 365d = ca. 56 kWh
Normalbetrieb - 7,5W * 2H * 365d = ca. 5,5 kWh
Summe ca. 61 kWh

Vergleich - Schätzwerte für meinen alten IBM:
ausgeschaltet - 1W x 22h x 365 = 8kWh
Normalbetrieb - 70W x 2h x 365 = 51kWh
Summe ca. 59kWh

Das Raspi-System spart also keinen Strom, Herstellungs- und Transportaufwand kommen in der Ökobilanz noch oben drauf... Kein schönes Ergebnis!

Das Problem ist, daß der Raspi

* einerseits kein suspend-to-RAM oder suspend-to-disk kann (siehe hier: https://github.com/raspberrypi/linux/issues/1281)
* und keine Echtzeituhr besitzt, die ihn einschalten könnte

Lösungsmöglichkeiten:

1. WittyPi (http://www.uugear.com/witty-pi…agement-for-raspberry-pi/)
Der WittyPi ist ein komplettes PowerManagement-System. Er kostet ca. 18€ zzgl. Versand und kann den Raspi zeitgesteuert ein- und ausschalten.
Vorteile:
* Komplettlösung, kein Löten nötig

Nachteile:
* Preis
* VDR bleibt am Netz und braucht weiterhin Strom (bei mir: Hub + Raspi ca. 1,5W). Man könnte das auf ein Netzteil reduzieren, dann muß man aber schon wieder löten.

2. RTC - bebastelt
Aus den bekannten Quellen gibt es Echtzeituhren (RTC - real time clock) für den Raspi für 1€ inkl Versand aus China. Diese sind zunächst mal nur dazu gedacht, einem netzlosen Raspi nach dessen Neustart die Uhrzeit zu sagen. Allerdings haben einige diese Chips auch eine "Alarm"-Funktion, einen Pin, der zu einer software-programmierbaren Uhrzeit den Pegel ändert. Daraus ließe ich IMHO mit wenig Aufwand eine Lösung bauen, die den Raspi einschaltet - und nach Verrichtung seiner Aufgaben alles (also Raspi und Hub) wieder komplett vom Stromnetz trennt.

Vorteile:
* Preis vielleicht 5€- ein RTC-Modul, 1-2 Transistoren, bißchen Kleinzeug, Relais (weil ich es für sinnvoll halte, auf der 230V-Seite zu schalten, sonst bleiben ja wieder 1-2W Leerlauf der Netzteile)
* Stromverbrauch 0W bei Stillstand möglich

Nachteile:
* Bastellösung - Lötkolben etc erforderlich.
* bei "0W": Raspi muß komplett neu booten (Zwischenlösungen denkbar)
* kein wake-on-LAN möglich

Soweit mein Forschungsstand.
Habe ich was übersehen? - Kennt jemand eine andere Möglichkeit, den Raspi im Leerlauf sparsamer zu kriegen?

Falls nein:
Hat jemand Lust, sich an so einem Projekt zu beteiligen? - Ich trau' mir zu, die Hardwareseite hinzukriegen, bin aber unfähig, was die Programmierung angeht. Das müßte aber alles IMHO mit ein paar Zeilen Shellskript und ein paar Anpassungen hinzukriegen sein.

Also - macht jemand mit?
Wenn jemand "hier" ruft, würde ich die Hardware-Seite und die Software-Anforderungen skizzieren.

Grüße aus Berlin,
Wolf

Nach anfänglichem Scheitern hab' ich mich inzwischen erfolgreich durch diese Anleitung gekämpft:

https://discourse.osmc.tv/t/ho…r-to-watch-live-tv/3256/9

Die Integration ist nicht unelegant - die Installation allerdings ein ziemliches Theater...
Allerdings hab' ich noch nicht rausgekriegt, wie ich die Schnittfunktion des VDR auslöse.

W

Moinsen, ich sitze auch in diesem Boot - raspi mit OSMC, auf das ein VDR draufsoll.
Wie heißt denn der Paketname des VDR? - Einfach "vdr" ? (-;

Und wie habt Ihr zwischenzeitlich die Kombi von Kodi / osmc und VDR gelöst?

Hallo an alle,

klasse, daß das burn-plugin wieder weiterentwickelt wird ! - Freue mich schon sehr auf etliche der projektierten Verbesserungen (z.B. Serienaufnahmen besser automatisch benamsen ist klasse!)

Gern wollte ich nochmal Copperhead in seinem Ansinnen bestärken, ffmpeg einzusetzen. Seit ich von DVB-T auf DVB-C umgestiegen bin, bekomme ich riesige Dateien auf den VDR. Dadurch passen nicht mal mehr 3 Stunden auf eine 4,7G-DVD - das macht nicht richtig Spaß. Habe ein bißchen mit ffmpeg rumprobiert - sogar bei 1:10 Kompressionsrate ist die Qualität für einfachere Archivierungszwecke bei mir durchaus ausreichend.

Noch ein Gedanke - vielleicht mag sie jemand aufgreifen:

Ich fände eine Energiespar-Option gut, bei der das burn-plugin das Abschalten des VDR freigeben könnte, sobald je einer der "Teiljobs", die im Laufe der DVD-Erstellung abgearbeitet werden, fertig ist. Viele DVDs sind bei mir nicht dringend und könnten so stromsparend abgearbeitet werden, wenn der Rechner eh für eine Aufnahme läuft (NB.: Jaja, Japan läßt grüßen…)

Leider kann ich nicht Skripten - Testen kann ich gern anbieten auf einem aktuellen easyvdr mit uralter Hartware…

Herzliche Grüße,

herrdeh

Servus Kupferschedl,

ich bin nicht die große ffmpeg-Leuchte… - aber vielleicht hilft die die -map-Option weiter:

Wenn du mit -i zum Beispiel sowas bekommst:

Stream #0.0[0x87]: Audio: liba52, s16
Stream #0.1[0x1e0]: Video: mpeg1video, yuv420p, 320x240 [PAR 1:1 DAR 4:3], 104857 kb/s, 24.00 tb(r)
Stream #0.2[0x1c0]: Audio: mp2, 44100 Hz, mono, s16, 96 kb/s

dann könntest Du zum Beispiel mit:

ffmpeg -i <Eingangsdatei> -map 0:1 -map 0:2 -acodec copy -vcodec copy <Ausgangsdatei>

nur die Ströme 0.1 und 0.2 auslesen - und 0.0 verwerfen. Vielleicht hülft es Dir.

Herzliche Grüße,

herrdeh

Hey suppppr,

ich stelle mich natürlich gern selbstlos als alpha-, beta- und gamma-Tester zur Verfügung.

Noch so einen Idee: Die Frage der requantifizierungsfaktoren scheint ja nicht so ganz trivial zu sein - und der qscale-Faktor ist womöglich noch schwieriger in den Griff zu kriegen. Ich vermute außerdem, daß die Komprimierungserfolge vom Ausgangsmaterial abhängen.

Könnte man nicht auf dem VDR eine Tabelle führen, in der Komprimierungs-Resultate und zugehörige qscale-Faktoren dauerhaft gespeichert werden. Für jedes neue Projekt könnte das Skript dann raussuchen, welcher qscale-Faktor für diese DVD am besten paßt - und im Laufe der Zeit auch noch quasi "dazulernen".

Herzliche Grüße,

herrdeh

Hallo Mac-Kollegen,

habe hier mit viel Doofheit das remote-plugin über Telnet zum Laufen bekommen. Hat jemand von Euch passende Einträge für die remote.conf, damit ich das auch vom Terminal von Mac OS X aus bedienen kann?

Bei mir geht grade "return" und "F12" - letzteres ruft offenbar gleich drei VDR-Seiten auf einmal auf… )-:

Dank und herzliche Grüße,

herrdeh

Hallo,

habe mal ein bißchen mit ffmpeg rumgespielt:

Wenn ich mit

ffmpeg -i 001.vdr -target pal-dvd -acodec copy -qscale 15 001.mpeg

eine VDR-Aufnahme umwandle und sie danach in *.vdr umbenenne, läßt sich daraus problemlos eine DVD machen.

Etwas problematischer ist die 002.vdr - da passiert es manchmal, daß kein Ton mehr zu hören ist, gelegentlich wurde die auch überhaupt nicht umgewandelt. Ich interpretiere (laienhaft) die Fehlermeldungen so, daß bei 002 und späteren keine Header-Infos da sind, die ffmpeg auslesen könnte und dann auf reines Raten angewiesen ist. Aber man sollte ja die Parameter aus der 001 an den Komprimierungsvorgang für 002, 003 ff. übergeben können.

-qscale 15 ist natürlich sehr brutal, man sieht dann sehr deutliche Klötzchen - aber dafür geht es auch ca. 1:10 runter…

Tonsynchronisationsprobleme hatte ich keine - kenne ich aber von ffmpeg ohnehin nicht…

Die Berechnung der Zieldatengröße scheint schwierig zu sein - im Anhang ist eine Graphik, wie qscale wirkt - man scheint das nicht richtig rechnen zu können… - Aber auch "Profi"Software hat da Probleme - "Toast" hat bei mir ein paar Filme von 7,3GB auf 3,6GB geschrumpft für eine 4,7er-DVD - das finde ich nun nicht ganz optimal…

Also ich denke, ffmpeg wäre weitergehender Versuche wert.

Herzliche Grüße,

herrdeh

Öhm, wer requantisiert denn dann? - Und kann man nicht da andere Parameter übergeben?

Herzliche Grüße,

herrdeh

Hallo,

das wär' klasse, wenn sich da mal jemand drum kümmern würde. In meinem (easy)VDR arbeitet wohl projectX als Requantisierer - kann man dem nicht einfach irgendwie klarmachen, es soll gegebenenfalls heftiger komprimieren und dabei eine schlechtere Qualität akzeptieren?

Habe gestern 5 Folgen á ca. 2,8GB mittels Toast auf ein ca. 3,6GB großes DVD-Image gebracht. Fast 20h Rechenzeit - soviel zur Effizienz professioneller Programme… - Aber die Qualität ist durchaus o.k. Die Orginale waren Analog-Filme aus den 1970ern - da ist die Schärfe eh' nicht sooo doll…

Es tät' mich sehr freuen, wenn wir da vorwärts kämen - für den, der mir als erster sagen kann, wie ich im Rahmen des burn-Plugins ein Kompressionsverhältnis von 1 : 5 bei ordentlicher Qualität hinbekomme, setze ich 6 Orginal Nürnberger Lebkuchen als Preis aus - echte Bäcker-Qualität, nicht den Fabrik-Plempel, den man außerhalb der fränkischen Lande für Lebkuchen hält.

Herzliche Grüße,

herrdeh

Öha - das hat also mit der Requantisierung der Filme nix zu tun.

Trotzdem bleibt für mich die Frage offen:
Mit ffmpeg kann ich einen DVB-C-Mitschnitt locker im Verhältnis 1 : 7 runterkomprimieren, und die Qualität des Resultats ist durchaus o.k.

Mit dem VDR-Requantisierer erreiche ich maximal 1 : 1;5 - da sollte doch noch Luft drin sein??? -

Herzliche Grüße,

herrdeh

Servus,

Dank für die Antwort.
o.k., ich habe also verstanden, daß nicht burn selbst, sondern der Requantisierer bestimmt, wie heftig komprimiert wird.

Was ich ganz am Anfang in einem burn-log gefunden habe:

Zitat

[render] INFO: [mpeg2enc] Quality factor: 8 (Quantisation = 9) (1=best, 31=worst)

Da scheint doch eine Begrenzung drin zu sein - mit einem "Quality factor" von 31 kriege ich wahrscheinlich ein grottige Qualität - aber halt auch viel mehr auf eine DVD. Kann ich das irgendwo vorgeben? Hat mpeg2enc eine config-Datei?

Herzliche Grüße,

herrdeh

Hallo Kollegen,

ich bin sehr begeistert von den Möglichkeiten des burn-Plugins.

Seit ich aber von DVB-T auf DVB-C umgestellt habe, sind meine Aufzeichnungen bei gleicher Länge erheblich größer geworden, so daß ich nun viel weniger Zeit auf eine DVD bekomme.

Außerdem ist es ärgerlich, eine Menge Rechenzeit damit zu verbraten, ein ISO zu erstellen, das sich dann als zu groß für einen Rohling herausstellt.

Gibt es im Zuge der Weiterentwicklung die Möglichkeiten, daß burn

• stärker komprimiert, als es das derzeit tut (wenn ich die logs richtig interpretiere, dann ist der "rescale"-Faktor derzeit auf 8 von 31 möglichen begrenzt), und
• eine Warnung ausgibt, wenn sich herausstellt, daß das Image nicht auf die vorher eingestellte Rohlings-Größe paßt?

Herzliche Grüße,

herrdeh