Video Treiber für Odroid-N2+ (softhdodroid)

jojo61: Es gibt da noch einen Bug bei der 4:3-Umschaltung. Einige wenige Sender wie RTL Nitro oder RTL up strahlen ja noch alte Sendungen in diesem Format aus. Die formatrichtige Umschaltung klappt beim ersten mal (mit kleiner Verzögerung), danach aber bei erneuter Anwahl des Senders nicht mehr. Zumindest nicht, wenn das sehr rasch geschieht - also Wiedergabe einer Aufnahme stoppen und sofort wieder starten, oder Channel vor- zurück. Wen man ein paar Sekunden wartet, scheint es zu klappen. Ich habe mal eine 23MB große Aufnahme hochgeladen, die man zum Testen verwenden kann. Ich blicke leider nicht durch, wie die Umschaltung der aspect ratio im Plugin funktioniert.

Danke, das funzt!

auf die Gefahr hin das ich hier etwas überlesen habe, hat schon jemand den VDR in der chroot als nicht root User zum laufen bekommen, also mit --user=vdr?

Hier hat das Ansatzweise geklappt nachdem ich den vdr User weiteren Gruppen hinzugefügt und die rechte der /dev/am* Devices angepasst habe. Nur ein Bild hatte ich nicht nur in Fragmenten.

Hintergrund der Frage ... das würde es einfacher machen die Rechte der Files im zentralen NFS Aufnahme Ordner zu erhalten.

Moin jojo61 ,

beim Starten von vdr mit dem Plugin auf der Konsole fiel mir auf, dass immer erstmal The codec is not open. amlSetVideoAxis geloggt wird. Ich konnte das soweit debuggen, dass es beim Aufruf dieser Funktion innerhalb von VideoSetOutputPosition kommt. Vielleicht kannst Du da gelegentlich mal einen Blick drauf werfen.

Wahrscheinlich hast Du auch schon bemerkt, dass sporadisch bei einem Kanalwechsel das Bild nicht schwarz wird, so als würde amlSetInt("/sys/class/video/disable_video", 1); nicht verarbeitet. Um das zu debuggen, habe ich den Code von amlSetInt etwas erweitert:

int amlSetInt(char *path, int val)
{
  int fd = open(path, O_WRONLY, 0644);
  int ret = 0;
  if (fd >= 0) {
      char bcmd[16];
      sprintf(bcmd, "%d", val);
      if (write(fd, bcmd, strlen(bcmd)) < 0) {
        ret = -1;
        printf("amlSetInt: error writing %d to %s!\n", val, path);
      }
      close(fd);
  } else {
      ret = -1;
      printf("amlSetInt: could not open device for writing %d to %s!\n", val, path);
  }
  if (ret)
    Debug(3, "%s: error writing %s",__FUNCTION__, path);
  return ret;
}

Das bringt hinsichtlich disable_video zwar keine Erkenntnisse (es wird kein Fehler geloggt, aber dennoch nicht schwarz). Aber man sieht nun einen anderen Fehler in VideoInit:

amlSetInt: could not open device for writing 1920 to /sys/class/graphics/fb0/scale_width!
amlSetInt: could not open device for writing 1080 to /sys/class/graphics/fb0/scale_height!

Es scheint, als wenn diese Pfade gar kein Schreibrecht haben:

-r--r--r-- 1 root root 4096 Apr  2 12:26 scale_height
-r--r--r-- 1 root root 4096 Apr  2 12:26 scale_width

Nachdem ich die Schreibrechte gesetzt habe:

chmod 0664 /sys/class/graphics/fb0/scale_width
chmod 0664 /sys/class/graphics/fb0/scale_height

wird nun ein anderer Fehler zurückgemeldet:

amlSetInt: error writing 1920 to /sys/class/graphics/fb0/scale_width!
amlSetInt: error writing 1080 to /sys/class/graphics/fb0/scale_height!

Ich vermute es liegt daran, dass die Einträge bei einer Abfrage auch keinen Wert, sondern offenbar einen String zurückliefern.:

CoreELEC:/sys/class/graphics/fb0 # cat scale_height

free_scale_height:1080

CoreELEC:/sys/class/graphics/fb0 # cat scale_width

free_scale_width:1920

Weiter bin ich noch nicht, vielleicht fällt Dir ja was ein...

Hast Du Dir auch das Problem The codec is not open. amlSetVideoAxis (siehe #586) mal angesehen?

jojo61 ich hätte jetzt einen Schnipsel von einer Minute bei dem das Bild häufig an der selben Stelle stehen bleibt während der Ton weiterläuft und wollte es dir auf deinen Bommel Speicher hochladen, leider scheint das Ding offline:

Internal Server Error

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

Danke, habs dir hochgeladen.

Es tritt relativ häufig wenn auch nicht immer auf - ich vermute schon einen Mini Fehler in der Aufnahme, allerdings sollte der das Frontend nicht so aus dem Tritt bringen: tut es ja bei softhdvaapi/softhdrm/sfthdcuvid auch nicht - die zeigen sich gänzlich unbeeindruckt so das man es nicht erkennen kann

noch ein Hinweis: Laut Hilfetext soll es die Option -m geben:

const char *CommandLineHelp(void)
{
    return "  -a device\taudio device (fe. alsa: hw:0,0 oss: /dev/dsp)\n"
        "  -p device\taudio device for pass-through (hw:0,1 or /dev/dsp1)\n"
        "  -c channel\taudio mixer channel name (fe. PCM)\n" 
        "  -m disable pip in mpeg2 streams\n" 
        "  -s\t\tstart in suspended mode\n"
        "  -D\t\tstart in detached mode\n"
        "  -w workaround\tenable/disable workarounds\n"
        "\talsa-driver-broken\tdisable broken alsa driver message\n"
        "\talsa-no-close-open\tdisable close open to fix alsa no sound bug\n"
        "\talsa-close-open-delay\tenable close open delay to fix no sound bug\n";
        
}

aber bei

[softhdodroid]
-a hw:CARD=AMLAUGESOUND,DEV=0 -m

kommt

Apr 14 13:25:57 CoreELEC vdr[4151]: [4151] loading plugin: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.3
Apr 14 13:25:57 CoreELEC vdr.sh[4151]: softhdodroid: invalid option -- 'm'
Apr 14 13:25:57 CoreELEC vdr.sh[4151]: Unknown option 'm'
Apr 14 13:25:57 CoreELEC vdr[4151]: [4151] deleting plugin: softhdodroid

jojo61 Mit dem letzten Commit aus deinem Github habe ich das Problem, dass z.B. bei Discovery HD das Bild alle paar Minuten für eine kurze Zeit stehen bleibt und dann weiterläuft. Der Ton ist dabei OK. Ich werde den Commit bei mir wieder entfernen...

Ja klar, wo kann ich es hochladen?