Einige Kanäle werden mit w_scan bei redirect für Cine CT nicht gefunden [war: w_scan + VDR fügen ORF eins HD nicht in channels.conf ein (DVB-C Liwest)]

So eine Spec gibt's nicht. Und so, wie ich die DVB-Entwickler (Anwesende ausgenommen) einschätze, wird das auch nicht so schnell kommen.
Wie wäre es denn mit einem zusätzlichen Parameter, mit dem man das demux-Device manuell vorgeben kann? Dann kann man w_scan passend zu seinem Treiber einstellen.

Lars.

Quote from wirbel

Wo genau steht in der DVB API die Zuordnung frontend <-> demux falls mehrere frontends auf einem device sind?
Ist das ein common agreement bei den DVB developern, dass jede(wirklich jede!) dvb hw mit mehreren frontends mehrere demux devices hat, je eines per frontend?

In der Vergangenheit gabe zu solchen Fragen nie echte Klarheit, wie solche hardware zu handeln ist.

Imho galt diese 1:1 Beziehung schon immer implizit. (Etwas anderes macht gar keinen Sinn, da es keine Möglichkeit gibt, um ein Frontend einem Demux zuzuordnen.) Vgl. http://linuxtv.org/downloads/v4l-dvb-apis/dvb_devices.html

Allerdings gab (gibt?) es Treiber, die das API diesbzgl. strapazieren, indem sie mehrere Frontends demux0 zuordnen, z.B. DVB-T frontend0, DVB-C frontend1. Von diesen Frontends kann dann allerdings immer nur genau eines geöffnet werden. Afaik gibt es dann nur demux0.

[frust]
Die API-Auslegung dieser Treiber halte ich für fragwürdig[*]. Allerdings macht bei v4l offenbar jeder, was er will. Und wenn es nach einem Jahr keiner gemerkt hat, wird behauptet, dies sei durch das API gedeckt. (Btw, so kamen auch die inkonsistenten Anzeigen für STR, SNR, BER, UNC beim Frontend-API zustande.)
[/frust]

Ich würde es so implementieren:
Zuerst versuchen, den 1:1 zugeordneten Demux zu öffnen (frontendX <-> demuxX). Falls dieser nicht existiert, demux0 nehmen.

Iirc hatte das alte scan-Tool einen Kommandozeilenparameter, um den Demux auszuwählen.

CU
Oliver

[*] Fairerweise muß man allerdings sagen, daß es bis vor einiger Zeit im DVB-API keine Möglichkeit gab, ein Frontend zwischen DVB-C <-> DVB-T umzuschalten.

Quote from UFO

Imho galt diese 1:1 Beziehung schon immer implizit. (Etwas anderes macht gar keinen Sinn, da es keine Möglichkeit gibt, um ein Frontend einem Demux zuzuordnen.) Vgl. http://linuxtv.org/downloads/v4l-dvb-apis/dvb_devices.html

Die alte DVB-API verwies in Chapter 3, DVB Demux Device auf folgendes:
The DVB demux device controls the lters of the DVB hardware/software. It can be
accessed through /dev/adapter0/demux0. Data types and and ioctl denitions
can be accessed by including linux/dvb/dmx.h in your application.

Hier steht nichts von einer Zuordnung. Im Gegenteil, es ist explizit von "/dev/adapter0/demux0" die Rede. Liest man in der Spec mit Datum von heute nach, ändert sich an der Ausssage gar nichts:

http://git.linuxtv.org/media_tree.git…a/dvb/demux.xml

Quote

Allerdings gab (gibt?) es Treiber, die das API diesbzgl. strapazieren, indem sie mehrere Frontends demux0 zuordnen, z.B. DVB-T frontend0, DVB-C frontend1. Von diesen Frontends kann dann allerdings immer nur genau eines geöffnet werden. Afaik gibt es dann nur demux0.

[frust]
Die API-Auslegung dieser Treiber halte ich für fragwürdig[*]. Allerdings macht bei v4l offenbar jeder, was er will. Und wenn es nach einem Jahr keiner gemerkt hat, wird behauptet, dies sei durch das API gedeckt. (Btw, so kamen auch die inkonsistenten Anzeigen für STR, SNR, BER, UNC beim Frontend-API zustande.)
[/frust]

Insofern ist das kein Bug in w_scan, der Bug liegt darin, dass Linux DVB Treiber Entwickler
a) unfähig sind ihre Arbeit korrekt zu dokumentieren
b) nach bereits existierender Doku zu coden
c) die API auf dem Stand der Technik zu halten.

Natürlich kann dann ein Anwendungsprogrammierer versuchen, um diese Fehler nachträglich herum zu programmieren, aber das ist ehrlich gesagt Unfug und macht das existierende Chaos noch größer.

Also wenn da steht

- /dev/dvb/adapterN/audioM
- /dev/dvb/adapterN/videoM
- /dev/dvb/adapterN/frontendM
- /dev/dvb/adapterN/netM
- /dev/dvb/adapterN/demuxM
- /dev/dvb/adapterN/dvrM
- /dev/dvb/adapterN/caM

dann bedeutet dies imho, daß Devices mit gleichem N und gleichem M zusammengehören.

Andernfalls könnte man ja auch argumentieren, daß adapter1/frontend0 dem adapter0/demux0 zugeordnet sein könnte, was total unsinnig wäre.

Aber hey, mir ist es letztendlich egal, was ihr da macht.

CU
Oliver

Es widerspricht nur eben der gleichen Doku ein paar Seiten weiter.

http://linuxtv.org/downloads/v4l-dvb-apis/dvb_demux.html

Ich denke es wird nicht lange dauern, und der nächste meint es würde wieder ganz anders sein.

Quote

Aber hey, mir ist es letztendlich egal, was ihr da macht.

+1