Entschuldigung für diese Grundsatzfrage...

...und ja, ich habe wirklich gegoogelt, aber weiß nicht, wie ich das beschreiben soll und habe so nichts gefunden.

Nachdem eine meine drei DVB-C Karten sich nicht als QAM256 tauglich erwiesen hat, habe ich nur noch zwei Karten in einem headless Server im Betrieb. Wenn ich nun eine Aufnahme am Laufen habe, kann ich mit der zweiten Karte nicht mehr streamen. Ist das richtig so? Channel unavailable. Ich verwende XBMC/VNSI und VOMP/streamdev, aber selbst, wenn ich per telnet auf den VDR gehe, kann nicht mehr auf einen Kanal sprigen. Auch das streamen von Sendern auf dem gleichen Transponder geht nicht.

Witzigerweise kann ich sehr wohl eine zweite Sendung aufnehmen, egal auf welchem Transponder.

Welche Einstellung habe ich übersehen? Eigentlich sollten zwei Karten reichen und DVB-C Karten sind so teuer...

Gruß, Karlson.

Hallo gehlhajo,

das hat mich etwas weiter gebracht. Ich habe die beiden mir eigentlich bekannten Parameter wieder in die setup.conf gepackt, die waren da irdendwie verschwunden.

Aber das Problem ist nicht behoben. Ich habe dann die PrimaryDVB und PrimaryLimit Parameter untersucht. In der alten, gut funktionierenden 3-Karten Variante stand
PrimaryDVB auf 3, Limit auf 0, wie es wohl sollte.

In der Zwei-Karten Variante aber auf 1. Da ich hier auch mit telnet nicht schalten konnte (554 error switching channel / not available), habe ich mal PrimaryDVB auf die
letzte Karte gesetzt, also 2. Nun konnte ich per telnet schalten. Allerdings, sobald ich eine Aufnahme starte, kann ich das nicht mehr. Wie sich die clients verhalten kann
ich hier aus dem Büro natürlich nicht testen.

Ich denke also, dass vdr sich eine der DVB-Karten schnappt und diese dann für streaming nicht mehr zur Verfügung stellt. Das wäre auch das beschriebene Verhalten,
für dass das dummydevice-plugin wohl konzipiert wurde, obwohl ich meinte gelesen zu haben, dass man das nicht mehr braucht.

Wir reden übrigens von einem 1.7.17er vdr, selbst kompiliert unter Debian, Grundlage die Sourcen von yaVDR. Und in den Logs steht nichts verdächtiges.

Ich kann ja nachher mal das dummydevice Plugin installieren und es als Primary Device nehmen, damit alle Budget DVB-C Cards (Easywatch & , Cablestar, denn die
TT C-1501 hatte massive QAM256 Probleme, also habe ich sie rausgenommen). Kernel 2.6.34.

Gruß,
Karlson.

Konichi wa giga san,

einen solchen Parameter habe ich nicht identifizieren können. Ich habe im Moment

streamdev-server.AllowSuspend = 1
streamdev-server.SuspendMode = 1
streamdev-server.StartServer = 1

in der setup.conf, ansonsten noch u.a.

PrimaryDVB = 2
PrimaryLimit = 0

Das Verhalten ist bei VOMP, welches streamdev verwendet das gleiche wie bei XBMC, welches VNSI benutzt.

Im syslog steht nicht viel. Am ehesten kann man noch beim VNSI was sehen. Wenn keine Aufnahme läuft, so kommt

Jul 25 19:51:52 riker vdr: [13958] VNSI: Client with ID 9 connected: 192.168.7.55:58270
Jul 25 19:51:52 riker vdr: [14356] VNSI: Welcome client 'XBMC Live stream receiver' with protocol version '1'
Jul 25 19:51:52 riker vdr: [14357] VNSI: Successfully found following device: 0x84e7800 (2) for receiving
Jul 25 19:51:52 riker vdr: [14357] VNSI: Creating new live Receiver
Jul 25 19:51:52 riker vdr: [14357] VNSI: Successfully switched to channel 3 - NDR FS HH
Jul 25 19:51:52 riker vdr: [14357] VNSI: Started streaming of channel 3 - NDR FS HH
Jul 25 19:51:52 riker vdr: [14359] receiver on device 2 thread started (pid=13942, tid=14359)
Jul 25 19:51:52 riker vdr: [14358] cLiveStreamer stream processor thread started (pid=13942, tid=14358)
Jul 25 19:51:52 riker vdr: [14360] TS buffer on device 2 thread started (pid=13942, tid=14360)
Jul 25 19:51:53 riker vdr: [14358] VNSI: streaming of channel started

Das geht. Nun starte ich eine Aufnahme auf ZDF HD und dann schalte ich erst auf einen Sender dieses Bouquets und dann auf NDR FS HH:

Jul 25 19:50:59 riker vdr: [13958] loading /var/lib/vdr/plugins/vnsiserver/allowed_hosts.conf
Jul 25 19:50:59 riker vdr: [13958] VNSI: Client with ID 5 connected: 192.168.7.55:58262
Jul 25 19:50:59 riker vdr: [14333] VNSI: Welcome client '(null)' with protocol version '1'
Jul 25 19:50:59 riker vdr: [13958] loading /var/lib/vdr/plugins/vnsiserver/allowed_hosts.conf
Jul 25 19:50:59 riker vdr: [13958] VNSI: Client with ID 6 connected: 192.168.7.55:58263
Jul 25 19:50:59 riker vdr: [14335] VNSI: Welcome client 'XBMC Live stream receiver' with protocol version '1'
Jul 25 19:50:59 riker vdr: [14336] VNSI: Successfully found following device: 0x84e7800 (2) for receiving
Jul 25 19:50:59 riker vdr: [14336] VNSI: Creating new live Receiver
Jul 25 19:50:59 riker vdr: [14336] VNSI: Successfully switched to channel 1 - Das Erste HD
Jul 25 19:50:59 riker vdr: [14336] VNSI: Started streaming of channel 1 - Das Erste HD
Jul 25 19:50:59 riker vdr: [14337] cLiveStreamer stream processor thread started (pid=13942, tid=14337)
Jul 25 19:51:00 riker vdr: [14337] VNSI: streaming of channel started
Jul 25 19:51:00 riker vdr: [14337] sending 23 buffered packets
Jul 25 19:51:00 riker vdr: [14337] sending 22 buffered packets
Jul 25 19:51:00 riker vdr: [14337] sending 7 buffered packets
Jul 25 19:51:01 riker vdr: [14337] sending 24 buffered packets
Jul 25 19:51:01 riker vdr: [14337] sending 18 buffered packets
Jul 25 19:51:05 riker vdr: [14336] VNSI-Error: cxSocket::read: read() error at 0/4
Jul 25 19:51:05 riker vdr: [14337] cLiveStreamer stream processor thread ended (pid=13942, tid=14337)
Jul 25 19:51:05 riker vdr: [14336] buffer stats: 1535208 (48%) used
Jul 25 19:51:06 riker vdr: [13958] loading /var/lib/vdr/plugins/vnsiserver/allowed_hosts.conf
Jul 25 19:51:06 riker vdr: [13958] VNSI: Client with ID 7 connected: 192.168.7.55:58266
Jul 25 19:51:06 riker vdr: [14338] VNSI: Welcome client 'XBMC Live stream receiver' with protocol version '1'
Jul 25 19:51:06 riker vdr: [14339] VNSI-Error: Can't get device for channel 3 - NDR FS HH
Jul 25 19:51:11 riker vdr: [13958] VNSI: Client with ID 6 seems to be disconnected, removing from client list
Jul 25 19:51:11 riker vdr: [13958] VNSI: cConnection::~cConnection()
Jul 25 19:51:11 riker vdr: [13958] VNSI: stopping cConnection thread ...
Jul 25 19:51:11 riker vdr: [13958] VNSI: done

Also kann er nach einer gestarteten Aufnahme:

Jul 25 19:50:15 riker vdr: [13942] switching device 2 to channel 2
Jul 25 19:50:15 riker vdr: [13942] timer 11 (2 1923-2025 'WISO') start
Jul 25 19:50:15 riker vdr: [13942] Title: 'WISO' Subtitle: ''
Jul 25 19:50:15 riker vdr: [13942] executing '/usr/lib/vdr/vdr-recordingaction before "/var/lib/video.00/WISO/2011-07-25.19.23.2-0.rec"'
Jul 25 19:50:15 riker recordingaction: executing /usr/share/vdr/recording-hooks/R10.naludump before recording /var/lib/video.00/WISO/2011-07-25.19.23.2-0.rec as shell script
Jul 25 19:50:15 riker recordingaction: executing /usr/share/vdr/recording-hooks/R90.custom before recording /var/lib/video.00/WISO/2011-07-25.19.23.2-0.rec as shell script
Jul 25 19:50:15 riker vdr: [13942] record /var/lib/video.00/WISO/2011-07-25.19.23.2-0.rec
Jul 25 19:50:15 riker vdr: [13942] creating directory /var/lib/video.00/WISO
Jul 25 19:50:15 riker vdr: [13942] creating directory /var/lib/video.00/WISO/2011-07-25.19.23.2-0.rec
Jul 25 19:50:15 riker vdr: [13942] recording to '/var/lib/video.00/WISO/2011-07-25.19.23.2-0.rec/00001.ts'
Jul 25 19:50:15 riker vdr: [14326] receiver on device 2 thread started (pid=13942, tid=14326)
Jul 25 19:50:15 riker vdr: [14325] recording thread started (pid=13942, tid=14325)

kein Device mehr für das Streamen finden. Anscheinend nimmt der VDR auf Device 2 auf, was wohl auch das Device ist, welches das VNSI Plugin bekommt, wenn es ohne Aufnahme auf VDR zugreift. Und was das Primary Device ist.

Hmmmm...hat noch jemand Ideen?

Gruß, Karlson.

Hallo Marten,

Zitat

Nur als Anmerkung vomp verwendet kein streamdev.

Ach so, ich dachte, das man das bräuchte. Das nährt aber in Summe meinen Verdacht, dass das Problem nicht in irgendwelchen Plugins liegt, sondern dass vdr sich einfach ein Device reserviert, um EPGs zu lesen oder wozu auch immer. Da werde ich mal weiter forschen.

Dr. Seltsam, ich meine mich auch zu erinnern, dass die Karte bei QAM256 keine Probleme hatte. Das einzige, was mich immer schon wunderte war, dass der eine Widerstand recht warm wurde, da dieser aber in einer Variante mit hoher "Leistungsfähigkeit" verwendet wurde, habe ich das "Absicht" interpretiert.

Nun denn, ich habe da so einen innovativen Kabelnetzbetreiber, der fast alles unverschlüsselt bringt, und ich hatte hin und wieder Probleme mit N3 und SIXX. Und wo ich das gerade so launig schreibe fällt mir auf, dass N3 gar nicht in QAM256 betrieben wird. Vielleicht sollte ich die doch noch mal anmailen, ob sie da was anders machen. Ein Frequenzproblem habe ich auch nicht so recht annehmen wollen, da N3 auf 402 MHz gesendet wird (ok, SIXX auf 690 MHz), denn das kommt quasi direkt aus der Glasfaser in den Medinwandler in den VDR.

Aber das ist auch gar nicht das hier diskutierte Problem. Ich befürchte, ich muss mir mal den Mechanismus anschauen, mit dem VDR seine Devices verwendet.

Oder müsste ich das dummydevice Plugin installiert haben, damit VDR das als Primary Device nimmt?

GrK.

Also dies hier meine ich:

Zitat

Für vdr 1.4.x ist das Plugin zwar empfohlen aber nicht zwingend notwendig. Ohne dummydevice wird einfach eine der Budget Karten zum Ausgabegerät erklärt, auch wenn tatsächlich nichts ausgeben werden kann. Beim Kanalwechsel über SVDRP kann dies jedoch zu Problemen führen. SVDRP schaltet grundsätzlich den Kanal des Ausgabegeräts. Ist dieses aber zur Zeit belegt, schlägt der Kanalwechsel fehl - selbst wenn eine andere Budget-Karte frei wäre.

Das beschreibt ja im Prinzip mein Problem.

GrK.

Mir fiel noch auf, dass ich früher das xineliboutput Plugin hatte und dieses ja mit --primary zum Primary Device wird. Ich habe es übersetzt, aber es scheint keine Abhilfe zu bringen. GrK.

Also, ich gebe es auf. Mit dummydevice und xineliboutput bekomme ich zwar vier Devices hin, die auch alle Primary Device werden können, oder sich vordrängeln, eines zu werden (ich vermute, das ist das xineliboutput --primary), aber wenn eine Aufnahme läuft bekomme ich ums verrecken keinen CHAN Befehl per telnet durch, der nicht auf dem gleichen Buquet ist.

Also muss ich entweder die C-1501 wieder flott bekommen oder eine neue DVB-C Karte für horrendes Geld erwerben, damit der VDR darauf fernsehen kann. Ich verstehe es nicht.

GrK.

So, langsam habe ich es. Durch das viele Probieren ist mir aufgefallen, dass der Knabe nie (in Worten NIE) Device 1 benutzt hat. Und dann sah ich, dass die Cablestar mit einem Mal einen lustigen neuen Tuner erkannt bekommt: statt des STV0297 nun Broadcom BCM3510 VSB/QAM frontend. Das ist definitiv nicht richtig.

Das merkwürdige Verhalten mit der QAM256-Schwäche der TT C-1501 kam ja m.E. auch angeflogen. Ich denke, ich mache mal einen Rollback vom 2.6.32 und 2.6.34 zum guten, alten 2.6.18 mit selbst übersetzten DVB-Treibern...

GrK.