Beiträge von geronimo

Moin,

konnte mich etwas früher abseilen, sodass ich schon neue Testergebnisse liefern kann:

Mit den erweiterten Ausgaben wird das Bild zunehmend klarer (zumindest bilde ich mir das ein
Wenn ich den vdr manuell starte, sieht es so schlecht nicht aus.
Was gelegentlich vorkommt sind Meldungen ala:

Jan 18 15:01:56 vdrhost vdr: [4888] read incomplete section - len = 3840, r = 785
Jan 18 15:03:41 vdrhost vdr: [4888] read incomplete section - len = 3837, r = 556
Jan 18 15:04:12 vdrhost vdr: [4888] read incomplete section - len = 3370, r = 708

Weiß nicht, welche Relevanz die Ausgaben haben, aber am Zeitstempel kann man sehen, dass das nicht soo häufig vorkommt.

Ganz anders sieht die Sache aus, wenn ich das erste Mal vdr-sxfe gestartet (und beendet) habe.
Dann läuft der vdr Amok mit solchen Meldungen:

Jan 18 14:45:31 vdrhost vdr: [4705] TRANSFER: packet was not accepted at first try (0)
Jan 18 14:45:31 vdrhost vdr: [4705] TRANSFER: will sleep 10ms with i=0

Gelegentlich läuft der Zähler auch über die 5 hoch, aber meistens wird bei i=0 geschlafen
Wenn dieser Zustand erreicht ist, ist es völlig egal, auf welchem Kanal ich vdr-sxfe beende.
Auch ein Kanalwechsel per svdrpsend bringt keine Linderung.
Schätze das ist ein Zeitpunkt, an dem nur Windows-Mittel (die Hand zum Salut) weiter helfen - denn auch ein emergency-exit ändert hier nichts.

Dann habe ich die Aufnahmen getestet:
Zuerst habe ich Timer erstellt, bei denen jeweils ein SD-Kanal als erster des Transponders kam. Bei den Aufnahmen konnte ich keine Fehler entdecken (wobei ich nicht wirklich weiß, wie ich feststellen soll, ob ein Frame fehlt).

Danach habe ich mehrere Aufnahmen gestartet und diesmal die HD-Kanäle als erste Timer angelegt.
Dabei kam es auf einem Device zu Fehlern und (wie ich vermutet hatte) sind alle Aufnahmen an (fast) der gleichen Stelle fehlerhaft (grobe Bildfehler).

Zur genaueren Annalüse hänge ich logs und so an.

Gruß Gero

P.S. zu den Bildern:
rec-test_01 ist vom ersten Test
rec-test_05 vom zweiten Test
rec-test_06 ist vom zweiten Test, als die Aufnahmen gerade beendet werden und die Nachbearbeitung läuft
Wie man sehen kann, langweilt sich die CPU bei max. 25% - erst bei der Nachbearbeitung darf sie etwas zulegen.
wait und busy-Werte dürften auch vernachlässigbar sein.

Hi chrisz,

der Effekt gibt schon zu denken!

Als erstes würde ich Dir empfehlen, den Speicher aufzurüsten.
2 Gig für SW-Raid kommt mir sehr wenig vor.
... und dann betreibst Du noch ne Ramdisk

Dann würde ich Bonnie auch eher in die Tonne kicken. Ist zu synthetisch.
Im VDR-Umfeld sind andere Daten gefragt und Aufnehmen auf ein Raid5 - eher fragwürdig.
Denn was Bonnie und Co als Transfer-Rate ausgeben ist keine Dauerrate.
Das Verhalten von Raid5 lässt sich auch gut mit mc visualisieren.
Wenn Du dort eine größere Datei kopierst, startet mc mit gigantischer Transferrate. Die pendelt sich langsam auf Normalniveau ein, um dann völlig auf 0 zu gehen.
Das ganze Spiel wiederholt sich zyklisch - d.h. ein Raid-Verbund hat immer ne Denkpause, wenn die Puffer geleert werden.
Damit muss natürlich auch der schreibenden Prozess umgehen können.

Ich teste die Transfer-Rate so:
- Testdatei > 10 Gig erstellen (wenn möglich für jeden Test eine separate Datei)
- unterschiedliche Testverzeichnisse erstellen
- die Testdatei in ein Testverzeichnis kopieren mit "time cp Datei Verzeichnis"
- aus den Zeitangaben und der Dateigröße kann man dann die "echte" Transfer-Rate berechnen.

Wenn Du rausfinden willst, wo der Flaschenhals ist, dann nimmst Du mehrere Sessions und lässt in jeder eine Kopieraktion ablaufen.
In einer weiteren Session startest Du dann Lese-Aktionen.
Das geht am einfachsten, indem Du Dir die absoluten Pfade von div. Textdateien in eine Datei kopierst (pro Textdatei eine Zeile)
dann in der Lese-Session ein "time cat $( < Datei-mit-Pfaden-zu-Textdateien )"

Wenn Du die Leseaktion startest, dürften die Schreibaktionen gehörig einbrechen.

Bei mir ist es so, wenn ich ne volle Wechselplatte auf den Server kopiere, dann sind das 500 Gig von einzelner Platte auf ein Software-Raid Level 5.
Wenn ich das mit "time cp -a Platte Raid" mache, komme ich nie auf die Transfer-Raten, die mir die üblichen Benchmarks ausspucken.
... und lass Dich nicht drausbringen - Software-Raid ist eine sehr gute Entscheidung - auch wenn man einen 3ware-Raidcontroller hat

Gruß Gero

Hi Sigi,

wenn Du statt "smartctl --attributes" - "smartctl -a" verwendest, bekommst Du alle notwendigen Informationen zu der Platte.
Daneben auch Hersteller, Modell, Serien-Nummer,

... und Serien-Nummer ist auf der Platte aufgedruckt - somit reduziert sich die Suche.

Gruß Gero

Moin moin,

Zitat

Nicht zwingend, das wäre z.B. typisch für eine Aufnahme bei deaktiviertem Emergency Exit,

Ist bei mir schon länger nicht deaktiviert.

Zitat

Das würde ich auch eher auf chronische Empfangsprobleme schieben.

Also davon konnte ich noch nix feststellen.
Es gibt je nach Konstellation unterschiedliche Effekte, aber die sind dynamisch.
Auch bei tvheadend ist es so, dass manchmal alle Transponder von beiden Karten auf 100% liegen und manchmal nicht.
Vielleicht liegt es daran, welcher Sender gerade aktiv ist, vielleicht liegt es auch an meinen Nachbarn - da kenne ich mich zu wenig aus in der Materie.
Ich werde demnächst mal die Kabel tauschen und dann weiter beobachten.

Zitat

Ich will aber VDR und nichts anderes.

Lach, vor nem guten Jahr, als ich das erste Mal tvheadend ausprobierte, dachte ich noch genauso.
Seither haben die verkorksten Aufnahmen deutlich zugenommen und während sich beim vdr nicht viel verbessert hat (von dem was mich interessiert), gab es bei tvheadend einen großen Schritt vorwärts.

Zitat

Mach das überhaupt irgendein Receiver in freier Wildbahn?

Wieviele Receiver gibt es denn in freier Wildbahn, die 3 oder mehr Empfänger haben?

Zitat

Wobei es auch unmöglich ist die "möglichen Transponder" automatisch zu ermitteln. Da müsste man dann seine Kanalliste von Hand zusammenbasteln.

Was soll dabei unmöglich sein?
tvheadend macht es, wirbelscan kann es auch und wenn man manche der Werte, die man auslesen kann noch verknüpfen würde, wäre noch viel mehr möglich.
Bei tvheadend dauert die Ermittlung von Transpondern und Services wenige Sekunden.
Ein Lauf mit wirbelscan dagegen mehrere Minuten - da ist sicher noch Optimierungspotential vorhanden.
Ich weiß ja nicht, wie verlässlich die Anzeige der Signalqualität bei tvheadend ist, aber wenn man die ermitteln kann, dann könnte man auch einen Schwellwert konfigurieren, bei dem alle Transponder mit schlechterer Signalqualität automatisch deaktivieren würde.

Wenn man von einem (überschreibbaren) Standard ausgeht, der jeweils den übermittelten Namen vom DVB als Kanal-Bezeichnung nimmt, dann bleibt es nach wie vor automatisierbar.
Erst Kanäle die manuell geändert werden, fallen aus dem Automatismus heraus.
Ich finde das so schlecht nicht.

Zitat

Mir wäre es aber wichtig gewesen, denn genau darum geht es doch bei der ganzen Sache!

Ok, dann eben nomml ein Test.
Bin aber die ganze Woche unterwegs, d.h. ich kann erst wieder am WE testen.

Gruß Gero

Zitat

Nur zur Sicherheit: und du hattest beim Testen auch wirklich eine Aufnahme parallel auf dem gleichen Device laufen, auf dem auch das Live-Signal empfangen wurde, und diese Aufnahme war dann fehlerhaft, oder?

Nein, während des Tests hatte ich keine Aufnahme laufen. War mir in dem Moment auch nicht wichtig.
Ich habe aber in letzter Zeit reichlich defekte Aufnahmen gelöscht - bei denen ich mir den Defekt nicht erklären konnte.
Die Aufnahmen mit 0 Sekunden Länge ist wohl ein Timer-Konflikt (für den ich aber noch keine Erklärung habe).
Wenn Aufnahmen von Sendungen mit 1,5 Stunden Dauer eine Länge von 15 Minuten haben und nur aus Pixelsalat bestehen, dann passt das genau zu meiner Theorie.

Argus hat ja auch geschrieben, dass er keine Probleme auf der SD-FF hat.

Deshalb gehe ich davon aus, dass es einen Unterschied zwischen den SD-FFs von DVB-S/S2 und DVB-C gibt.
Nachdem Du geschrieben hattest, dass bei Dir der Überlauf nur einmal stattgefunden hat, reichte mir der Beweis des Gegenteils zur Stützung meiner These.

Ich will nicht ausschließen, dass es bei DVB-C noch mehr Effekte gibt, die Du vielleicht weder kennst, noch für wahrscheinlich hältst.
Für mich ist die Ursache meiner Probleme logisch und nachvollziehbar. Wer die Pakete letztlich verliert, ist für mich als Anwender völlig irrelevant.

Als QS-Mensch behaupte ich, dass die Verantwortlichkeiten in der Anwendung nicht richtig verteilt sind.
Um wieviel die Komplexität steigen müsste/würde, wenn man es richtig machen würde, lasse ich mal offen.
Du hast ja schon gesagt, dass Du an der Stelle nix ändern magst.

Gruß Gero

Zitat

Kamen die "not accepted" Meldungen bei dir im "Normalbetrieb", also mit einem Signal, das das Ausgabedevice auch wirklich darstellen konnte? Oder war das bereits der Fehlerfall?

Es war der Fehlerfall.

Erst dachte ich, es würde was bringen, wenn ich im VDR einen SD-Standardkanal wähle, aber dem ist nicht so.
Wenn der VDR z.B. aufwacht um eine HD-Aufnahme aufzunehmen und es gibt keinen anderen Timer, dann wird der Empfänger auf HD umgeschaltet, der mit dem Frontend verbunden ist.
Da aber nur die SD-FF als Frontend ständig aktiv ist, geht eine solche Aufnahme immer schief.

Jetzt könnte ich zwar immer Pseudo-Timer anlegen, wenn so eine Situation auftritt, aber das ist mühselig und lästig.
Schließlich bin ich viel unterwegs und erwarte eigentlich™, dass der VDR auch in meiner Abwesenheit zuverlässig funktioniert.

Bei gleicher Konstellation reicht z.B. wenn ich das Frontend für xineliboutput auf meinem Desktop starte. Dann sind die Fehler weg.

Weiß nicht, ob das ermittelt werden kann, aber wenn z.B. für eine HD-Aufnahme umgeschalten werden muss und es gibt eine SD-FF im System, könnte ja auf einen SD-Sender aus dem gleichen Transponder geschaltet werden. Dann wäre eine Aufnahme mit weniger Fehlern möglich

Zitat

Der Sleep soll im Wesentlichen dazu dienen, daß das Ausgabedevice Zeit bekommt, seine Daten zu verarbeiten und das anstehende Paket anzunehmen.

Das mag ja sein - auch wenn ich es für völlig falsch halte, dass das Device auf einen Empfänger wartet.
Fakt ist, dass in der Zeit Pakete verloren gehen.
Wo - weiß ich nicht.
Auf jeden Fall sind solche Aufnahmen schlicht unbrauchbar - die Frames passen überhaupt nicht mehr zusammen und der Decoder kommt völlig aus dem Tritt, sodass auch Abstürze u.ä. vorkommen können.

Gero

Moin,

motzen und schmollen passt nicht zusammen, deshalb hier die Testergebnisse.
Musste den Patch etwas modifizieren, damit ich auch was sehe und posten kann.
Der Patch sieht jetzt so aus:

Index: vdr-1.7.28/transfer.c
===================================================================
--- vdr-1.7.28.orig/transfer.c  2013-01-10 17:39:42.319165567 +0100
+++ vdr-1.7.28/transfer.c       2013-01-13 09:54:01.583352773 +0100
@@ -42,12 +42,22 @@
      // buffering here. The TS packets *must* get through here! However, every
      // now and then there may be conditions where the packet just can't be
      // handled when offered the first time, so that's why we try several times:
-     for (int i = 0; i < 100; i++) {
-         if (PlayTs(Data, Length) > 0)
+     for (int i = 0; i < 5; i++) {
+         if (PlayTs(Data, Length) > 0) {
+            retriesExceeded = false;
             return;
+            }
+         isyslog("TRANSFER: packet was not accepted at first try (%d)", i);
+         if (retriesExceeded) {
+            esyslog("TRANSFER: retries already exceeded, won't sleep");
+
+            return;
+            }
+         esyslog("TRANSFER: will sleep 10ms with i=%d", i);
          cCondWait::SleepMs(10);
          }
-     esyslog("ERROR: TS packet not accepted in Transfer Mode");
+     retriesExceeded = true;
+     esyslog("TRANSFER: TS packet not accepted in Transfer Mode");
      }
 }
 
Index: vdr-1.7.28/transfer.h
===================================================================
--- vdr-1.7.28.orig/transfer.h  2010-01-29 17:38:09.000000000 +0100
+++ vdr-1.7.28/transfer.h       2013-01-13 08:55:39.050277064 +0100
@@ -17,6 +17,7 @@
 class cTransfer : public cReceiver, public cPlayer {
 private:
   cPatPmtGenerator patPmtGenerator;
+  bool retriesExceeded;
 protected:
   virtual void Activate(bool On);
   virtual void Receive(uchar *Data, int Length);

die Log-Ausgaben sind im Anhang.

Zitat

Die Testausgabe hat bei mir ein einziges Mal zugeschlagen und '1' ausgegeben. Also trat der Problemfall hier nie auf.

So wie es aussieht, stellt sich die Situation unter DVB-C etwas anders dar.
Ob die Schuld jetzt an der HW, der Firmware oder dem Treiber liegt, kann ich nicht beurteilen.

Zitat

Kann man sich hier wirklich leisten 10ms auf die CPU zu verzichten nur
um einen anderen Thread die CPU zu geben?

Vorausgesetzt ich habe den Ablauf richtig verstanden, dann gibt es pro Karte/device nur einen Fred.
Der sleep kommt also nur einer anderen Karte zugute - falls es denn eine solche gibt und die auch mit der Zeit was anfangen kann.
Wenn also auf einer Karte 4 Aufnahmen laufen und ein Empfänger hat mal Probleme, sind an der Stelle alle Aufnahmen defekt.
... oder eben wenn die SD-FF einen HD-Stream (oder auch SD-Stream mit hoher Bitrate) bekommt, sind alle Aufnahmen futsch, auch wenn der Fernseher aus ist, bzw. niemand ein Interesse an den Ausgaben der SD-FF hat.

VDR heißt ja -Recorder und nicht Live-TV-Zuspieler - also sollten die Aufnahmen die höchste Prio/Sicherheit genießen und alles andere müsste sich dem unterordnen.
So ist zumindest meine Ansicht.

Hier noch ein Denkanstoß für die Zeit nach 2.0:
Bei tvheadend kann man alle Transponder einer Karte separat aktivieren/deaktivieren.
Pro Transponder werden alle möglichen Streams als Services aufgeführt. Auch jeden Service kann man einzeln aktivieren/deaktivieren.
Jedem Service kann man einen Freitext zuordnen.
Dieser Freitext ist dann das, was unter Kanäle aufgelistet wird (völlig unabhängig von dem Text, der im Service via DVB übermittelt wird).
So kann jeder mehrere Services zu einem Kanal zusammenfassen oder auch gleiche Services unterschiedlicher Karten unterschiedlich benennen.
Jedem Kanal kann dann noch ein Tag (auch Freitext) zugeordnet werden.
Diese Tags können bei den Timern alternativ zu den Kanal-Bezeichnungen verwendet werden.

Ich finde - so kann mit überschaubarem Aufwand eine sehr flexible Lösung geschaffen werden.
... und man kann den Empfänger der SD-FF noch für unwichtige Sender verwenden.

Adapter-3 zeigt die Signalqualtität der KNC-1 (erste Generation), Adapter-2 die Signalqualtität einer neueren Generation (gleiches Model).
Beide Karten bedienen sich aus der gleichen Kabel-Anschluss-Dose - ich hätte also gleiche Werte erwartet.
Die SD-FF hat kein Antennenkabel, da der Empfänger ja bereits per Plugin-Parameter abgeschaltet wurde.

Gruß Gero

Zitat

Unter Ubuntu (und evtl. ja auch unter Debian) geht's sogar noch kürzer (dget ist bei mir Version 2.11.6ubuntu1.4):

Danke für den Dip - aber ich denke, das hat sich für absehbare Zeit erledigt.
Nach dem Kommentar hat sich meine Bereitschaft, den vdr weiter zu bringen in Wohlgefallen aufgelöst.
Wer so dickköpfig seine Fehlentscheidungen zementiert, darf von mir aus machen was er will - ich brauch das jedenfalls nimmer.
Es gibt so viele gute Leute hier im Forum, die sonstwas dafür tun würden, den vdr weiter zu bringen, Fehler zu beseitigen und Fehlkonstruktionen richtig zu machen ...
Mai Oma meinte dazu nur: wer nicht will, der hat schon.

Der Typ vom Konkurrenz-Projekt war auch ein dickköpfiger Einzelgänger - zumindest bis vor nem guten Jahr.
Dann hat er wohl eingesehen, dass Teamarbeit auch Vorteile bringen kann und hat Projektleiter, Entwickler und Distributionsentwickler in sein Team (was davor nur aus ihm selbst bestand) aufgenommen.
... und was sollich sagen: seitdem geht das richtig ab dort
Neue Codebasis, stabile Build-Umgebung, Repository gerade gezogen - natürlich auch alle anderen Viehtscher eines PPA ...
Selbstverständlich gibt es eine Roadmap, Tickets für Fehler und Wünsche, Transparenz für Interessierte, ...
... eigentlich alles, was man sich im gemütlichen und erfolgreichen Miteinander so wünscht.
Inzwischen gibt es die Anwendung für die großen Distributionen daugerecht ...
... und neue Themen werden aufgeschlossen angegangen. So auch 4k
Ich bin völlig begeistert und werde jetzt wexeln.

Jedem, der den vdr nicht nur standalone betreibt, kann ich nur empfehlen, TVHeadend auszuprobieren.
Das Frontend ist noch nicht der Bringer, aber wer mit xbmc zufrieden ist, der wird es mit showtime auch sein.
Ich brauch weder noch - da ich mit meiner Streaming-Lösung zufrieden bin. Es gibt also keinen Grund für mich, dem VDR nachzutrauern

Wer mich erreichen möchte, möge dies bitte per Emaille tun, PMs werde ich wahrscheinlich nimmer so regelmäßig lesen.

In diesem Sinne: habe die Ehre.

Zitat

eine Änderung des Receiver-Handlings wird (zumindest auf absehbare Zeit) nicht stattfinden.

Alles klar! Danke für den Hinweis.

Dann lass ich Dich. Habe genug anderes zu tun.

Gero

Kleine Rückmeldung von der Front

Nach der großartigen Steilvorlage von mini habe ich mir eine VDR-VM aufgesetzt, den ganzen Kladderadatsch runtergezogen und neu verpanscht ...
... und dann auf mein Backend gespielt.

Ergebnis:
wie erwartet war das nicht des Pudels Kern - äh, meine natürlich es war nicht die Lösung des Problems.
Bei Umschaltung auf HD-Sender bekomme ich einen Sekundenbruchteil noch Ton und dann gibt's weder Ton noch Bild.
Glücklicherweise tut das OSD noch, sodass der vdr noch bedienbar ist.

Auf den meisten SD-Sendern habbich mit der Änderung MPeg-Artefackte en masse - man kann schon nicht mehr von einer Bildstörung reden. Die Störung hat die Regel und wird von gelegentlichen Bildern ohne Störung gestört
Ich hatte erst den Verdacht, dass es an der Bitrate der Sender liegt, aber dem ist nicht so.
Die meisten gestörten Sender hatten so ± 4 MBit Video und dann fand ich doch tatsächlich einen Sender, der fast keine Artefackte zeigte - auch bei ca. 4 MBit Video.

Ich habe dann auch gleich wieder einen Rollback durchgeführt, um zum Standard zurück zu kehren.

Ich versuche mich mal an einer Umsetzung meiner Idee - allerdings brauch ich da (später?) etwas Unterstützung beim Erstellen des Patches über mehrere Dateien.
Da ich mich erst wieder in den VDR eindenken muss, kann es schon etwas dauern.

Gruß Gero

Zitat

Damit kannst du das komplette Quellpaket und den debian-Ordner mit den vorhandenen Patches herunterladen (einfach die .dsc-Datei als Argument übergeben).

Whow - der Dip war megafett!

Jetzt habbisch ein blaues Doppelkinn, weil mir die Kinnlade so hart auf die Tischplatte viel.
Ich verneige mich vor dem yavdr-Team. Ihr habt nen geilen Job gemacht.
Ich kann's noch garnicht richtig glauben: dget ausgeführt, Paketbau durchgeführt, Archiv auffen vdr kopiert, neu gestartet und es funzt

Menno!!! - yavdr auf debian-Basis - ja, doch - damit kann ich mich anfreunden
Schätze yavdr steht kurz davor, ein neues Fänchen zu bekommen

Gruß Gero

Hoy, das ist mir vorhin glatt durch die Lappen

Zitat

Wir hätten da noch was in unseren vdr-PPAs - das sollte sich eigentlich auch unter Debian gegen den eigenen VDR bauen lassen:

Danke für den Hinweis. Klingt interessant.
Ist das *tar.gz das Source-Paket?

Weiß nicht, funzt das mit dem Einbinden des Launchpads als debian-Archiv?
Schätze mal, Ubuntu wird andere Abhängigkeiten haben.

Wird wahrscheinlich sinnvoller sein, das source-Paket manuell zu saugen und dann die Tuhls drauf los lassen. Oder?

Gero

Yo - danke alle mitanand

Da haben sich ein paar Postings überschnitten.
An der Frequenz also - ah jetzt ja.
Dann sieht die channels.conf natürlich ganz anders aus.

Gut dass wir drüber gesprochen haben
Danke.

Gero

P.S. Die Kabelfritzen sind doch Dachplatten
Bei 2df sind HD und SD auf dem gleichen Transpondern, bei ARD nich :frust

Zitat

Zumindest bei KabelBW in Heidelberg sind "Das Erste" und "Das Erste HD" auf zwei unterschiedlichen Transpondern

Ok, dann bin ich wohl völlig schief gewickelt

Ich dachte bislang, wenn die Bezeichnung nach dem ersten Strichpunkt übereinstimmt, dann wären die Sender vom gleichen Bouquet.
Weiß jetzt nicht, ist Bouquet das gleiche wie Transponder?
Vielleicht habe ich das ja auch falsch verstanden?
Unter Bouquet verstehe ich eine Ansammlung von Sendern, die gleichzeitig von einer Karte aufgenommen werden können.
Wenn es nicht die Bezeichnung nach dem Strichpunkt ist, woran erkenne ich dann Sender die zum gleichen Bouquet/Transponder gehören?

Gruß Gero

Moin!

danke, dass Ihr mitgedacht habt, aber ich habe DVB-C.
Wenn ich nicht völlig auf der falschen Spur bin, dann gibt es dort keine Unterscheidung der Polarisation

Zitat

evt. Noch mit devstatus die Verteilung der Dvb Karten anschauen.

Mein Distributions-Ersteller hat beschlossen, dass man devstatus nimmer braucht
Die Option habe ich also leider nimmer.

Gruß Gero

Moin!

wie sieht es mit dem dev-status-Plugin aus?
Gibt es den Entwickler noch, oder wurde das Plugin aufgegeben?
Derzeit scheint es aus den debian-Distributionen rausgeflogen zu sein.
Bevor das verwahrlost, würde ich es adoptieren

Gruß Gero

Hallo,

nach den Enttäuschungen der letzten HD-Aufnahmen der ersten Reihe wollte ich Aufnahmen parallel in SD und HD aufnehmen.
Dachte, das sollte locker gehen - schließlich entstammen beide Kanäle ja dem gleichen Bouquet.

Kaum hatte ich jedoch die Timer gesetzt, erhalte ich Konfliktmeldungen, so als ob der VDR die HD und SD von unterschiedlichen Karten aufnehmen will.
Wie kommt das?
Habe ich da einen Fehler gemacht, ist die Konflikt-Erkennung fehlerhaft oder würden die Aufnahmen wieder in die Hose gehen?
Im angehängten Bild ist Kanal 1 ARD-HD und Kanal 38 ARD-SD.

Gruß Gero

... um mal wieder auf den eigentlichen Sinn des Freds zurück zu kommen ...

Zitat

Die Hemmungen sind dort doch auch schon längst gefallen

Yo, da nervt auch besonders krass die erste Reihe!

Inzwischen ist wohl auch die Bitraten-Reduzierung bei den Kabelbetreibern umgesetzt worden.
Als ich mir den Wallander - vor dem Frost ansah, war ich schockiert. Zuerst dachte ich, dass Kabel D soviel schlechter senden würde, als KabelBW, aber dann fand ich raus, dass meine neueren Aufnahmen genauso aussahen.
Sowie einige Bildbereiche nicht ganz scharf fokussiert waren, konnte man die MPeg-Artefackte sehen. Das bedeutet, dass HD-Aufnahmen von Kabelkunden inzwischen schlechter aussehen, als SD-Aufnahmen - ich könnt abkotzen
Ein Wallander in HD mit 1,6 Gig - vor nicht allzulanger Zeit wären das noch 8-9 Gig gewesen.
Erst dachte ich, dass Kabel-D soviel schlechter senden würde, als KabelBW, aber die jüngsten Aufnahmen zeigten mir, dass die Kwalität auch bei KabelBW angekommen ist.

Also ich werde wieder mehr aus der Videothek ausleihen. So einen Schrott aufzunehmen und mich dann beim Anschauen (wo ich eigentlich entspannen will) zu ärgern, das muss nicht sein. Inzwischen ist SD hochskaliert auf dem LCD sogar besser, als eine HD-Aufnahme!

Die Kabel-Gesellschaften haben sich einen Bärendienst erwiesen. So werden sie auch noch die letzten Befürworter verlieren

Gruß Gero

Zitat

aber in meins kommt nur, was ich will.

Klare Ansage ... Du ... lebst allein?

Übrigens: vorhin gelesen, dass bei tvheadend bereits am 4k-Transfer-Modus gearbeitet wird.
Es bleibt spannend

Gruß Gero

Zitat

aber wahrscheinlicher ist, dass es einfacher ist, ein "kaputtes" Plugin zu reparieren.

Da hast Du ganz sicher recht!

Nur bin ich nicht der Ansicht, dass der einfachste Weg unbedingt der richtige Weg ist.
Wie gesagt, ich bin nicht an einer schnellen Lösung interessiert. Ich fände es auch völlig akzeptabel, wenn Klaus meint, dass eine solche Änderung erst nach 2.0 kommt.
Mir wäre es lieber, dass es richtig gemacht wird.

... und unter richtig finde ich, dass der VDR-Core nicht von Plugins gestört oder ganz aus dem Tritt gebracht werden kann.
Klar ist das aufwändiger.

Nichts desto trotz kann und sollte das Plugin auch repariert werden.
Die Kernfunktionalität vor externen Fehler zu schützen finde ich nicht nur bei Webservern sinnvoll.
Der Linux-Kernel wurde umgestrickt, damit Userspace-Probleme nicht das System an sich infizieren.
Beim apache-Webserver ist es ähnlich und ich finde, jede größere Anwendung, die externe Plugins erlaubt, sollte ein Mindestmaß an Selbstschutz praktizieren.

... und beim VDR finde ich, dass die Empfängerseite bzw. eben jetzt der device-Loop das schwächste Glied in der Kette ist.
Wenn nur ein Empfänger Mist macht, dann funktioniert kein Empfänger mehr.
Ich denke nicht, dass das einfach vernachlässigt werden sollte.

Gruß Gero