Beiträge von frankschm

@DaVu @scratchy

Ich versuche mal die zusätzlichen Infos zu geben. Auf dem Server läuft als Hypervisor Proxmox (Debian Buster). Dateisystem ist ext4. Gleiches gilt für die VM (Debian Buster, ext4). Beides läuft auf einer SSD. Die betreffende Daten-Festplatte, auf der sich die Datei befindet, ist eine WDRed, die direkt (pass-through)" an die VM durchgereicht wird. Auch hier ext4 als Dateisystem.
Zugriff erfolgt über SSH (Putty) und PubKey mit dem Benutzer frank. Die Datei album.nfo gehört Benutzer frank und ist in Gruppe users, Rechte lauten 640. Für meine Löschversuche hab ich mir über su root-Rechte gegeben. Datei lässt sich ohne Problem in Benutzer root und Gruppe root mit Rechten 777 ändern. Trotzdem ist ein Löschen nicht möglich.
Gerne gebe ich weitere Infos. Auch ich habe bald 10 jahre Erfahrung mit Linux und auch mir ist sowas noch nicht untergekommen.

@Simaryp

Nein Datei ist nicht geöffnet. Server hatte ich auch mal neu gestartet. Meine Internetrecherche hat mir auch keine zusätzlichen Lösungsansätze gebracht.
Prinzipiell kann ich mit dem Zustand leben, aber mich interessiert die Ursache. Ist mir in vielen Jahren der Linux-Nutzung noch nicht untergekommen.

Hallo zusammen,
ich habe ein Problem mit dem Löschen einer Datei, das nur indirekt mit Kodi zu tun hat.

Ausgangssituation:

• NAS in einer VM auf meinem Home-Server (Debian Buster mit OpenMediaVault)
• Verbindung über SSH
• Habe die Musikdatenbank in Kodi in album.nfo und artist.nfo in entsprechende Verzeichnisse auf NAS exportiert.
• Eine so erstellte album.nfo-Datei lässt sich ums Verrecken nicht mehr löschen.

Was ich bisher probiert habe:

• rm / rm -f
• Entfernen evtl. vorhadener Attribute: chattr -a -i - danach - rm / rm -f
• Löschen über Inode: ls -i - danach - find $NAME_OF_DIRECTORY -inum $INODENUM -exec /bin/rm -f {} \;

In allen Fällen erhalte ich folgende Meldung: rm: das Entfernen von 'album.nfo' ist nicht möglich: Die Operation ist nicht erlaubt

Was mit der Datei noch möglich ist:

• Editieren und speichern
• Rechte ändern mit chmod
• Eigentümer/gruppe ändern mit chown
• Kopieren der Datei mit cp (mv geht nicht!)
• Löschen der mit cp kopierten Datei.

Wer hat noch Ideen, wie man die Datei los werden kann?

Gruß
Frank

Hallo zusammen,

seit heute Mittag funktionieren bei mir die HLS5-Streams nicht mehr. Eine Umstellung auf HLS7 brachte Abhilfe. Hat Zattoo die HLS5-Streams abgestellt oder ist da Problem temporär? Hat noch jemand das Gleiche festgestellt?

Hallo zusammen,

in den Einstellungen zur Energieeinstellung gibt es denn Eintrag 'Senden Sie diskrete Ein/Aus Befehle'. Kann mir jemand sagen, was diese Einstellung bewirkt und was mit diskret gemeint ist?

@Proxan

die Angabe eines PID-Files ist nicht notwendig und für 'Type=simple' auch nicht empfohlen (siehe Service unit configuration unter Option 'PIDFILE=')

Einfach die Update- Funktion im Menü nutzen. Danach ging es bei mir wieder.

Funktioniert wieder. Danke.

@easy4me

ich kann @Tiburon bestätigen. Auch hier die Meldung 'Service provider unavailable!'. Nach Anschauen meiner Logs werden seit vorgestern Mittag (23.03.21) keine Daten mehr gezogen. Auch 'Open Grabber Settings' erzeugt gleiche Fehlermeldung. Die Daten im 'userfile' sind i.O..
Wieder was von Zattoo geändert? Ich nutze einen Zattoo Premium Account.

Habs auf - erledigt!

Hallo zusammen,

ich will gerade die Batterien der Fernbedienung meiner Shield Pro 2019 wechseln und bekomme ums Verrecken nicht die Abdeckung entfernt. Habe mir schon die Hinweise in der Bedienunganleitung und in diversen YouTube-Videos angeschaut. Es bewegt sich nichts! Ich würde mich auch nicht gerade als Schluffi bezeichnen, an der Kraft sollte es nicht liegen (mein Daumen hat schon ausgepräte Druckstellen). Hatte jemand schon mal das gleiche Problem und eventuell einen Tipp?

@bumblebee,
ich habe die API auf einem Rasberry Pi 3B installiert. Umschaltzeiten von anderen Geräten im LAN bei mir 1,5 - 2 s (Tvheadend, PVR IPTV Simple Client).

Hallo @easy4me,
zu untem genannten Thema ist mir aufgefallen, das der Sender ZDFneo korrekt funktioniert (beide Audiospuren vorhanden, die auch ausgewählt werden können). Sind dort die Audiofragmente (Stereo) anders als bei den anderen Sendern? Warum macht Zattoo das?
Übrigens: Bei diesem "normal" funktionierenden Sender sind die Umschaltzeiten sehr schnell (auch etwas schneller, als bei der alten API).

Zitat von easy4me

Vielen Dank für deine Spende!

Die verlängerten Umschaltzeiten sind nach der Ersteinrichtung normal, beim wiederholten Zappen sollten diese sich wieder normalisieren.

Das Phänomen mit den Tonspuren habe ich bei HLS7 mit meinem tvHeadend-Setup übrigens auch. Den Grund dafür habe ich bereits gefunden.

Es werden bei der Bereitstellung der Streams einzelne Fragmente der Video- und Audiospuren vom Player geladen. Das Problem ist, dass die Video- und Audiospuren bei HLS7 unterschiedlich lang sind.

Beispiel:
Videofragment: 4 Sekunden
Audiofragment (Stereo): 3,2 Sekunden
Audiofragment (Dolby): 4 Sekunden

Aufgrund dieser Unterschiede kann ffmpeg die Streams nicht mehr zeitgleich zusammenfügen, weshalb die Tonspuren ggf. komplett wegfallen. Im tvHeadend-Log kann man eine entsprechende Meldung (tsfix) beobachten.

Ich habe eventuell eine Lösung dafür, diese müsste ich aber erstmal testen.

Alles anzeigen

Werde ich mal probieren - Danke!

Si - dann aber kein Dolby

@easy4me
die 'tsfix'-Meldungen habe ich schon mehrfach gesehen. Konnte mir aber keinen Reim drauf machen. Entgegen meiner vorherigen Aussage habe ich gerade festgestellt, das Sender mit nur einer Tonspur (N24Doku, CNN) immer stumm bleiben, egal welche Tonspuren ich in der API einstelle.
Eine Lösung wäre natürlich super.

@easy4me
ich habe ein Problem mit den Tonspuren bei Nutzung von TVHeadend festgestellt: Einstellung in der API: 1. Tonspur AAC, 2. Tonspur Dolby 5.1
Im PVR IPTV Simple Client in Kodi werden beide Tonspuren dargestellt und die 1.Tonspur ist vorausgewählt. Über Einstellungen/Audio kann die Tonspur gewechselt werden – perfekt.
Im TVHClient in Kodi ist jedoch die 2. Tonspur vorausgewählt. Über Einstellungen/Audio kann die Tonspur zudem nicht gewechselt werden (Menüpunkt inaktiv). Dies führt zu dem umschönen Effekt, das bei Sendern mit nur einer Tonspur (N24 Doku, CNN) der Sender stumm bleibt, da keine 2. Tonspur (die ja vorausgewählt ist) vorhanden ist.
Was kann hier die Ursache sein?
Ist nur eine Tonspur in der API vorausgewählt, gibt es kein Auffälligkeiten. Nehme ich einen Sender auf, sind in der erzeugten Datei alle Tonspuren vorhanden.

Weiterhin haben sich die Umschaltzeiten im TVHClient in Kodi mehr als verdoppelt (ca. 6s!), während sie sich im PVR IPTV Simple Client in Kodi spürbar verringert haben (ca. 1,5s). Vielleicht jemand eine Idee zur Ursache hierzu?

@easy4me ich hab dir mal eine kleine Spende für die tolle Arbeit zukommen lassen.

P.S. Die in meinem vorherigen Beitrag gemachten Beobachtungen zum ffmpeg-Parameter –ri haben sich erübrigt (Problem tritt nicht mehr auf!)

@easy4me im Anhang findest einen entsprechenden Journal-Auszug mit loglevel [definition=12,0]debug[/definition].

Hallo @easy4me,

Glückwunsch zu deiner neuen API - bin begeistert! Hier mal meine ersten Erfahrungen:

APi läuft bei mir auf einem Debian-LXC. WebGUI lässt sich bisher fehlerfrei verwenden. Mit PVR IPTV Simple Client unter LibreELEC läuft alles bisher anstandslos.
Probleme hatte ich mit TVHeadend (läuft auf gleicher Debain-LXC). Wenn ich als Server AUTO wähle, bekomme ich folgenden Fehler:
[infobox]tvheadend[166]: spawn: [tcp @ 0x55fd86e17640] Failed to resolve hostname auto-hls7-live.zahs.tv: Name or service not known[/infobox]
Ist eine Server vorausgewählt, verschwindet der Fehler.
Die über die WebGUI erstellen pipe-Adressen funktionieren so nicht. Mit gesetztem Parameter -re [pipe://ffmpeg -loglevel fatal -re -i....] funktioniert der Aufruf nicht.
[infobox]tvheadend[166]: spawn: [hls,applehttp @ 0x55d61e7abe40] HLS request for url 'https://1und1-ess1901-1-hls7-live.zahs.tv/HD_zdf/......', offset 0, playlist 2
tvheadend[166]: spawn: [hls,applehttp @ 0x55d61e7abe40] Opening 'https://1und1-ess1901-1-hls7-live.zahs.tv/HD_zdf/......' for reading
tvheadend[166]: spawn: [hls,applehttp @ 0x562323f2ae40] HLS request for url 'https://1und1-ess1901-1-hls7-live.zahs.tv/HD_ard/......', offset 0, playlist 2
tvheadend[166]: spawn: [hls,applehttp @ 0x562323f2ae40] Opening 'https://1und1-ess1901-1-hls7-live.zahs.tv/HD_ard/......' for reading
tvheadend[166]: mpegts: favorites.m3u - ZDF HD in ZattooTVH - scan no data, failed
tvheadend[166]: subscription: 0013: "scan" unsubscribing
tvheadend[166]: mpegts: favorites.m3u - Das Erste HD in ZattooTVH - scan no data, failed
tvheadend[166]: subscription: 0012: "scan" unsubscribing
[/infobox]
Entferne ich den Parameter -re ,funktionert der Aufruf problemlos.

So weit mein erster Eindruck.

Hatte ich schon vermutet. Fehler ist mir bereits heute am späten Nachmittag aufgefallen. Da der Fehler über Web und Android-App nicht auftritt ist vermutlich doch was geändert worden. @easy4me - Kannst du den Fehler bestätigen?