Posts by Paulaner

villeneuve wrote:

Ist es mit ext4 überhaupt sinnvoll, andauernd einen fsck zu machen oder warum macht Ihr den wie es scheint so oft?

So oft mache ich den "fsck" nicht, nur aller paar Wochen mal, wenn ich gerade mal Lust dazu habe.

Nur früher war der eben extrem lang und man konnte ja in der Zeit nichts weiter am System machen.

Wichtiger war für mich die Performance beim Löschen großer Dateien. Und die ist mit dem aktuellen ext4 wirklich super schnell.

SurfaceCleanerZ wrote:

WD lügt genau wie die anderen beiden HDD Hersteller, ob es SMR ist oder nicht.

Ich habe seit sehr vielen Jahren immer WD-Festplatten im Einsatz und bin damit bisher gut gefahren.

Die Sache mit dem heimlichen Einsatz von SMR an Stelle von CMR war schon nicht ganz koscher.

Deswegen habe ich ja auch geschaut, welche der WD-RED-Platten kein SMR einsetzen und diese gekauft.

Nach meinen Recherchen sind es die WD40EFAX-Platten, die SMR einsetzen.

Die von mir gekauften WD40EFRX benutzen dagegen noch das CMR-Verfahren zum Schreiben der Daten.

Ich habe heute Nachmittag mal den Selbstversuch gestartet und eine der neuen 4TB-Platten in den VDR-PC eingebaut und mit ext4 formatiert.

Dann zwei VDR-Aufnahmen von ca. 10GB hinkopiert und in *-TEST umbenannt und anschließend über Symlinks dem VDR-Aufnahmeverzeichnis bekannt gemacht.

Dann habe ich ein paar Test gemacht und bin mit dem aktuellen ext4-Dateisystem mehr als zufrieden.

Plattencheck mit e2fsck: Ging sehr flott, ca. 15 Sekunden für gesamte 4TB-Platte!

Löschen einer Aufnahme über das VDR-Menü: Super schnell, keine Verzögerung o.ä. spürbar!

Direktes Löschen einer Aufnahme über die Konsole: Ebenfalls super schnell, ohne irgendwelche Verzögerungen!

Fazit:

Das aktuelle ext4-Dateisystem ist wirklich sehr, sehr viel schneller und performanter als das alte ext3/ext4-Dateisystem.

Für mich gibt es damit keinen Grund mehr für die Archiv- und Media-Festplatten ein anderes Dateisystem einzusetzen.

Okay, XFS benutze ich ja auch schon seit Jahren.

Der Grund um damals von ext3/ext4 auf XFS zu wechseln waren ja die zu diesem Zeitpunkt schlechte Performance von ext3/ext4 bei großen Partitionen und bei großen Dateien.

Meine Frage ist also immer noch:

Hat sich die Performance bei ext4 inzwischen so gut verbessert, das man dies wieder auch bei großen Partitionen und großen Dateien einsetzen kann?

Vermutlich werde ich es einfach kommende Woche mal selber testen und eine Platte mit ext4 formatieren und dann testen, wie die Performance ist.

Ob XFS obsolet ist kann ich nicht beurteilen!

Wichtig für mich wäre noch, ob das Löschen großer Dateien (so. ca. 10GB) auch besser geworden ist!

Früher gab es bei ext3/ext4-Dateisystemen doch schon merkliche Wartezeiten, in denen das System mit dem Löschen beschäftigt war.

Bei meiner neuen SSD merke ich da wirklich nichts mehr, da geht das Löschen sehr flott!

lnj wrote:

Before the update, there was never an error?

I'm not sure about this.

But I've got this failure in the last time 2 times.

Meine jetzigen beiden Archiv-Festplatten für die VDR-Aufnahmen und die KODI-Medien ist in letzter Zeit ständig voll belegt.

Deshalb habe ich mir nun 2 neue Festplatten von Western-Digital WD40EFRX gekauft, die ich demnächst einbauen will und jetzt bin ich mir nicht ganz sicher, welches Dateisystem "ext4" oder "XFS" ich verwenden soll.

Als ich vor einigen Jahren die Festplatten eingebaut habe, war das ext3/ext4-Dateisystem noch elendig langsam bei großen Dateien und großen Partitionen..

Beim Löschen einer größeren Datei dauerte es schon mehrere Sekunden und der Plattencheck mit "fsck" dauerte Ewigkeiten.

Deshalb hatte ich damals dann als Dateisystem XFS verwendet, was ja mit den großen Dateien keinerlei Probleme hat. Das Löschen und der Plattencheck geht wirklich flott.

Bei XFS gibt es nur Probleme, wenn mal ein "harter" Reset erfolgt bzw. einfach die Stromversorgung ausfällt. Dann gibt es oftmals Schwierigkeiten, dass die Platten nicht mehr erkannt werden und man muss dann mit xfs_repair versuchen das die Platte wieder gelesen werden kann. Ging auch immer wieder, macht nur manchmal etwas Mühe.

Vor einem Jahr habe ich mir eine größere SSD (2TB) für das System und die VDR-Aufnahmen zugelegt. Die Aufnahme-Partition dieser SSD ist ca. 1.8TB groß und mit "ext4" als Dateisystem.

Wenn ich hier jetzt eine größere Aufnahme lösche oder auch einen Plattenchek mit "e2fsck" mache, dann geht das genauso flott, wie auf den Archiv-Platten mit "XFS"-Dateisystem.

Frage hierzu:

Liegt das nun nur an der SSD, die ja wesentlich schneller als eine "normale" Festplatte ist?

Oder ist das aktuellere "ext4" inzwischen wesentlich besser, d.h. schneller geworden, beim Umgang mit großen Dateien und dem Plattencheck?

Was soll ich also in Zukunft für ein Dateisystem für meine Archiv-Platten nehmen: EXT4 oder XFS?

Meine Tendenz geht zu "ext4" (wegen der positiven Erfahrung mit der neuen großen SSD), wenn das wirklich inzwischen besser/scheller geworden sein soll, als es vor Jahren war.

Heute ist mir das innerhalb der letzten Tage zum 2. Mal passiert, dass ich kurz nach dem der VDR gebootet hat und das TV-Bild zusehen war, der VDR sich neu gestartet hat.

Passiert ist das, nach dem ich das OSD öffnen wollte. Da war dann schlagartig das TV-Bild weg und es war dann das "vaVDR"-Startbild zu sehen und der VDR hat sich neu gestartet.

Danach war dann alles gut, der VDR lies sich fehlerfrei bedienen und es gab keinerlei Probleme mehr.

Hier mal der relevante Auszug aus dem syslog um 15:55:45 Uhr , als das passierte:

Mir sagen die Meldungen leider nicht viel, und der Fehler kam bisher ja nur 2 mal vor und dann eben nicht bei jedem Neustart.

Liegt das evtl. am von mir verwendeten vdr-plugin-softhddevice-cuvid, was ja vor ein paar Tagen eine Aktualisierung bekam?

Mein System ist auf dem aktuellsten stand, d.h. es hat alle aktuellen Updates von yavdr-bionic und auch von Ubuntu, falls das wichtig ist.

Vielleicht kann einer der Profis damit etwas anfangen und erkennt, was die Ursache sein könnte.

So, jetzt konnte ich die geänderten Scripte testen.

Funktioniert wieder alles, bis auf das "removeresume.sh" da fehlt m.M. nach das Minuszeichen vor dem 2. "name"!

Originalscript funktioniert bei mir nicht:

find "$1" -maxdepth 1 -type f \( -name "resume" -o name "resume.*" \) -delete

Sollte also m.M. nach so richtig sein:

find "$1" -maxdepth 1 -type f \( -name "resume" -o -name "resume.*" \) -delete

Dann funktioniert auch bei mir das Löschen der alten Wiedergabeposition.

seahawk1986 + kfb77

danke für Eure schnelle Hilfe.

Werde ich Testen, sobals der VDR zum rumprobieren wieder frei ist!

Heute ist mir aufgefallen, dass das Löschen der Schnittmarken, Wiedergabeposition usw. über das OSD nicht mehr funktioniert.

Bisher habe ich z.B. immer über Menü -> Aufzeichnungen -> Befehle (rote Taste) -> Schnittmarken entfernen die durch Markad

automatisch erstellten Schnittmarken entfernt. Das geht jetzt nicht mehr.

Auch das Löschen der Wiedergabeposition über dasgleiche Befehle-Menü funktioniert nicht mehr.

Ich habe bewusst nichts geändert, was damit irgendwie zusammen hängt.

Die /var/cache/vdr/reccmds.conf sieht so aus:

Die entsprechenden Dateien liegen auch wie schon immer unter /usr/local/bin

So sieht die "removeresume" aus:

Und so die "removemarks" :

Jetzt bin ich mit meinem Latein am Ende, da diese Befehle seit Jahren immer funktioniert haben.

Das Einzigste was mir bei den beiden Dateien auffällt ist, das es einmal -o name heißt und dann -o -name .

Und beide Befehle haben auch bis vor Kurzem noch funktioniert, aber als ich es heute wiedermal gebraucht habe ging es nicht mehr!

Gibt es irgendeine Stelle, wo ich ansetzen kann, damit die "Befehle" wieder funktionieren?

pluto ,

Du hast nicht das hier besprochene vdr-plugin-softhddevice-cuvid im Einsatz, sondern das vdr-plugin-softhdcuvid !

Das sind ganz unterschiedliche Plugins!

Hhhmm, bei mir steht der Deinterlacer bereits überall auf "Adaptive".

Jetzt habe ich das mal auf "Bob" gesetzt und siehe da die Laufschrift ist einwandfrei.

Und zum testen ob das auch so bleibt wieder zurück auf "Adaptive" gesetzt und die Laufschrift ist immer noch einwandfrei!

Keine Ahnung warum, aber ich habe eigentlich nichts gemacht, außer einmal den Wert geändert und dann wieder zurückgesetzt und die Laufschrift ist und bleibt gut.

Jetzt habe ich zur Sicherheit den gesamten Bereich vom "softhddevice" in der setup.conf gelöscht und nach dem Neustart alles wieder auf meine Werte eingestellt. Jetzt läuft alles einwandfrei und ohne irgendwelche Bildprobleme.

Keine Ahnung woher vorher die Probleme gekommen sind, denn ich habe ja nun alles wieder auf die Ausgangswerte gesetzt und alles ist gut.

Ich hoffe das war es jetzt und es bleibt auch so!

Danke für die schnelle Hilfe und den Tipp mit der setup.conf

Seit einigen Tagen ist mir aufgefallen, dass das Bild mit dem vdr-plugin-softhddevice-cuvid irgendwie komisch aussieht.

Ganz deutlich ist es mir dann aufgefallen bei horizontalen Schwenks in Bildern und dann vor allem beim Newsticker (Laufzeile) von WELT.

Hier mal das Bild dazu:

Beim rumprobieren habe ich dann mal das vdr-plugin-softhddevice_v1.03 installiert (also das Plugin ohne cuvid) und da gibt es keine Bildfehler.

Hier das Bild dazu:

Jetzt habe ich wieder das vdr-plugin-softhddevice-cuvid_v1.0.3 installiert und dabei zuerst vergessen in der zugehörigen softhddevice.conf das cuvid wieder zu aktivieren. Und siehe da, die Laufzeile des Newstickers wurde sauber dargestellt.

Sobald ich aber das cuvid mit -v cuvid aktiviere ist die Laufschrift wieder total zerhackt.

Kann das Verhalten jemand bestätigen, oder habe ich hier nur ein Problem?

lnj

I have tested the new version softhddevice_1.0.3 and it works perfekt!

I get a PIP picture with all TV channels, scrambled and also unscrambled! Good work!

Thanks

Great.

I have no hurry, I can wait till you fix the problem!

My screen resolution is 1920 x 1080p50

I found an other user with the same issue in this thread:

PIP looks very strange

In my opinion the video resolution has no effect for this, because if I use the same channel for the main and the PIP picture I get the same results.

But FYI the video resolution of RTL-HD is 1080i und the resolution of ZDF-HD is 720p

I have deleted all plugin settings for the softhddevice-Plugin and I get also the same results like before!

lnj wrote:

Have you checked the encoded main and encoded pip?

I didn't know what you mean with this.

The unscrambling of scrambled channels work perfect, without any issues.

I have 3 DVB-S2-Tuner in my VDR and I can unscramble 3 different channels at the same time.

On the other side I have made some test with different position of the PIP picture and I hope this will help to find out a solution.

FYI the ZDF-HD is a free TV channel and RTL-HD is a scrambled TV channel.

If I use the PIP Picture in the right top corner with this settings I get the following results:

Bild 1: Hauptbild RTL-HD -> PIP ZDF-HD = rtl-hd - pip-zdf-hd_top.jpg

Bild 2: Hauptbild ZDF-HD -> PIP RTL-HD = zdf-hd - pip-rtl-hd_top.jpg

Im syslog finden sich dazu folgende Einträge:

If I set the PIP picture approximatly in the middle of the right side with this settings I get the following results:

Bild 1: Hauptbild RTL-HD -> PIP ZDF-HD = rtl-hd - pip-zdf-hd_middle.jpg

Bild 2: Hauptbild ZDF-HD -> PIP RTL-HD = zdf-hd - pip-rtl-hd_middle.jpg

Pictures with the PIP picture position on the right bottom corner I have send in the first article of this thread.

This all shows for my opinion that the scrambling works perfekt, but if the PIP picture is a scrambled TV channel we get a not correct view.

I hope this will help you!

seahawk1986 wrote:

Das Paket ffmpeg mit dem ffmpeg-Binary kannst du dir bei Bedarf installieren ...

Für welche Zwecke würde man denn die ffmpeg-Binarys benötigen?