Posts by Slartibartfas042

Slartibartfas042

... oder auch simpel und einfach ein CPU-Kühler aus der Verankerung gelöst, Speicher oder Netzteil defekt (thermische Fehler?), Festplatte am sterben? Hört sich nach einem zwar reproduzierbaren, aber eher vom Fehlerbild her nicht ganz eindeutigen Fehler an. Der Fehler könnte sehr gut auch von der verwendeten Hardware her stammen.

Wenn er das letzte mal beim konvertieren ohne gleichzeitigen Empfang ausgestiegen ist dürfte wohl auch der Notfall-Reboot beim fehlen von Signal als Rebootursache ausscheiden. Oder lief zu dem Zeitpunkt gerade auch noch eine Aufnahme nebenbei?

MfG
Wolfgang

Slartibartfas042

Dann schau doch einfach mal in die Spezifikation von S/PDIF (aka TOSLINK) unter

http://www.epanorama.net/documents/audio/spdif.html

beim Stichwort 1. Jitter (clock phase noise) findest du da folgendes:

"This really only affects sound of the signal going directly to a DAC. If you're running into a computer, the computer is effectively going to be reclocking everything. Same applies also to CD-recoders, DAT tape decs and similar devices. Even modern DACs have typically a small buffer and reclocking circuitry, so the jitter is not so big problem nowadays that it used to be."

Und genau diesen Effekt hatte ich auch mit meinem Hinweis auf die "Digitaltechnik" gemeint. Die Daten sind zum Zeitpunkt des abspielens längst in einem Ringpuffer, die "Abspiellogik" wird in einem vernünftigen Gerät locker in der Lage sein, einen genügend großen Puffer mit eher unhörbarem akustischem Effekt die PLL für den Samplingraten-Takt nachzuregeln damit der Ringpuffer niemals leerläuft. (in dem Dokument oben "reclocking circuitry" genannt.).

Alle Angaben und Messungen in den Links auf http://www.stereophile.com beziehen sich auf ein System mit 0 Bit Puffer (!), das man in der Praxis (hoffentlich?) nicht mehr vorfinden sollte. Sobald du einen Puffer zwischenschaltest und das S/PDIF Signal nicht direkt ungepuffert in Analogwerte wandeln lässt ergibt sich dieses Problem aber gar nicht mehr! Außerdem schreibt der Autor hier über seinen Versuchsaufbau: "ie, the exact sample time can vary by +1ns or -1ns". Und genau das ist ja der Trick! Im Gerät bzw. auf dem Transportweg kann der Samplingzeitpunkt selbst nicht mehr variieren! Dieser ist durch die Aufahmeseite festgelegt. Und nachdem wir von Wiedergabe sprechen benötigen wir also noch einen ich nenne es einfach einmal "Wiedergabetakt" welcher durch den oben angesprochenen reclocking-circuit (oder eine entsprechende Logik in Software) aus dem Inhalt des Ringpuffers generiert werden muß.

Somit gilt also wohl doch wieder "Bit ist Bit", da die reclocking-Mimik natürlich dafür sorgen muß, dass es hier zu keinen Sprüngen bzw. merklichen Schwankungen im Takt kommt.

Slartibartfas042

... das hat jetzt mit VDR genau [was] zu tun?

Slartibartfas042

OK, selbst wenn man davon ausgeht, dass es bei Kunststoff-LWL keine so genau definierte Brechung gäbe und somit max. 20 Mbit/s eindeutig erkennbar wären. Gehen wir von einer Bittiefe von 16 Bit aus dann wäre das immer noch 1.3 MSamples/s, Overhead abrechnen kommen wir also trotzdem noch ganz locker auf mehr als 1 MSamples/s mögliche Abtastrate mit 16 Bit Tiefe!

Und hören vom Jitter? Wenn die digitalen Daten bis zum Zeitpunkt der Verwendung (oder Gültigkeit) rechtzeitig eingetroffen sind dann ist der exakte Zeitpunkt des eintreffens völlig belanglos. Sie müssen halt innerhalb des Zeitfensters rechtzeitig eingetroffen sein und dann werden Jitter etc. durch die DAC's selbst und nicht durch den Transportweg verursacht. Das ist ja eben genau der große Vorteil von Digitaltechnik, dass mit Samples gearbeitet wird und diese im Prinzip bis zum Zeitpunkt der Verwendung zu beliebiger Zeit vorher eintreffen können. Auch ein verrauschtes Signal über Coax wird - so lange das Verhältnis Nutzsignal zu Rauschsignal nicht zu gering wird um das Nutzsignal zu erkennen - am Klang des ganzen absolut nichts ändern. Entweder sind die Bit's da oder nicht. Bit-kipper wird wirklich jeder hören, alles andere kann sich absolut nicht ändern. (==> Digitaltechnik)

Auch wenn das einigen namhaften "audiophilen" Herstellern von High-End Kabeln sicherlich gar nicht gefällt!

Slartibartfas042

Quote from SurfaceCleanerZ

Hi,

Schreib das doch ins Wiki, dort findet man es wieder.

MfG Stefan

Apropos: Login im Wiki erzeugen ist nicht mehr möglich, da Captcha V.1 verwendet wird welches es aber nicht mehr gibt.

Slartibartfas042

Hmm, die Limitierung kann ich reinschreiben, der Rest war ja eigentlich mein ganz persönlicher Fall von "PEBCAK".

Slartibartfas042

Super! Danke für die Info - das bringt mich schon mal ein gutes Stück weiter beim Verständnis für das ganze.
Ich schaue mir das ganze aber auf alle Fälle weiter etwas intensiver an, schon alleine aus rein persönlichem Interesse.

Wolfgang

Slartibartfas042

Quote from kls

Es ist allerdings eine "stable", keine "developer" Version ;-).

Dennoch viel Spaß damit!

Klaus

Genau das richtige und genau zum richtigen Zeitpunkt für mich!

Aber eine vielleicht dumme Frage an Klaus kls: Warum gibt es denn die Limits bei den Parametern in der Datei device.h (auch noch in 2.4.0):

#define MAXDEVICES 16 // the maximum number of devices in the system

#define MAXPIDHANDLES 64 // the maximum number of different PIDs per device

#define MAXRECEIVERS 16 // the maximum number of receivers per device

Da ich sehr viele Radiostreams parallel entweder von SAT oder Kabel verarbeite führt diese Einstellung dazu, dass komischerweise nicht mehr als (aktuell) 26 Stationen parallel möglich sind. Setze ich diese 3 Werte hoch so kann ich bisher auch locker 40 oder mehr Sender streamen. Gibt es einen Grund für diese Einschränkung? Ich verstehe ehrlich gesagt auch nicht ganz *warum* alle 3 Werte hochgesetzt werden müssen, eigentlich schauen 16 Karten mit je 16 Tunern und 64 PIDs pro Tuner für mich völlig ausreichend aus, aber ich interpretiere da bestimmt etwas falsch?

DANKE für Deine tolle Entwicklungsarbeit, Klaus!

Slartibartfas042

Quote from hopsi

Vielleicht ganz trivial: Platte voll?

Ansonsten bitte einen eigenen Thread dazu aufmachen, das gehört hier nicht zum Thema.

Schreibst du über Netzwerk auf ein NFS/ SMB Share? Oder eine lokale Platte? Welches Filesystem? Platte *wirklich* nicht voll? Teste doch einfach mal indem du eine Datei anlegst und da etwas rein schreibst, manche Filesysteme reservieren Platz für internen Hokuspokus, die Tools zeigen diesen aber als freien Platz an.

Slartibartfas042

Quote from iNOB

Kein Schreibrecht auf der Aufnahmeplatte?

... hätte auch keine Datei angelegt.

Slartibartfas042

Wird zwar nicht allzu viele treffen, da die Aufgabenstellung mit mehr als 50 Streams aus einem VDR-Server wohl doch eher nicht allzu alltäglich sein dürfte. Aber vielleicht interessiert's den einen oder anderen ja doch - die oben gemachten Einstellungen waren an und für sich genau das was die Lösung gebracht hat. *Mein* Problem war allerdings, dass mir das Debian-Startscript ein Bein gestellt hat und nicht das im Suchpfad befindliche Binary gestartet hat....

Wenn man also von SUSE und den normalerweise recht gut gebauten Paketen dafür gewohnt ist dass immer nur das im Suchpfad auftaucht was auch von den Startscripten verwendet wird und (Admin-Krankheit?) zu faul ist jedes mal die komplette Befehlszeile reinzuhacken und deshalb ein "service vdr start" bevorzugt dann schiesst man sich damit logischerweise in den Fuß. Weil: Suchpfad /usr/local/bin/vdr, augerufener Pfad im Script: /usr/bin/vdr....

vdr --version bringt also über Suchpfad die erwartete Ausgabe mit eigenem Kompilat, service vdr ..... greift auf falsches Binary zu.

Lange Rede, gar kein Sinn - wer nicht die (evtl. sogar unnötigen?) Einschränkungen bei den Clients und Karten haben will kann mit obigen Defines die Limits auch tatsächlich ordentlich anheben. Aktuell läuft die Maschine mit VDR und Auswertung aller Radiostreams für 40 Kanäle absolut ungerührt. Beanspruchung durch den VDR ist im Vergleich zum Rest fast nicht messbar. Und im Vergleich zum Durchsatz einer aktuellen Grafikkarte auf dem PCI-E Bus ist der Durchsatz bei üblichen Programmen auch eher lächerlich. Vermutlich wurden die Einschränkungen mit Blick auf SOC's mit wenig Speicher und wenig Performance vorgenommen, für ausgewachsene PC's (ab Pentium III aufwärts und mit halbwegs vernünftigem Speicher) dürften sich die Patches aber nicht auswirken.

Slartibartfas042

Quote from dippes

Werde ich noch probieren,muß nur noch einen besorgen.Werde es mal mit meinem Smartphone versuchen.

Smartphone ist aber auch nur mäßig geeignet, da gibt's auch keinen genormten 1V Pegel... Ist ja eigentlich eher ein Kopfhörerausgang der nur zum Line-Out mißbraucht wird.

Ahso - wenn du mit Smartphone testest dann regle aber bitte die Lautstärke auf niedrige Pegel runter, sonst kannst du genau aus dem Grund auch wieder das Clipping bekommen.

Slartibartfas042

Quote from dippes

Was meint ihr zu diesem DAC ?

Würde dies eher den Wunsch zu High End erfüllen?

Prinzipiell könnte der in die richtige Richtung gehen.

oder vielleicht auch sowas, immerhin sind hier die DAC's selbst zumindest schon mal von Burr-Brown, also einem der ganz großen im Bereich Audio-DACs:

https://www.ebay.de/itm/HiFi-Paral…nYAAOSwX61ZGYGR

Frage ist halt:

Was genau möchtest du mit dem Raspberry machen, was stört dich an der Hifi-Beere und ... hörst du wirklich den Unterschied oder glaubst du das nur?

Slartibartfas042

Quote from dippes

Kannst du einen empfehlen?

Leider kann ich hier absolut keinerlei Empfehlungen geben da ich den Anspruch noch nie an den kleinen (Raspberry) gestellt habe

Kommerzielle DACs zu kaufen ist wohl auch eher ein hypothetischer Weg, da bewegt man sich dank audiophilem Geschwurbel und Mythen sehr schnell im Bereich mehrerer hundert Euros alleine für den DAC. Der Punkt ist eben - es liegt nicht ausschliesslich am DAC-Chip selbst. Die Klangqualität steht und fällt an und für sich mit den nachgeschalteten Filtern, welche deutlich hörbar den Klang von ein und der selben Signalquelle dann entweder rau und flach oder detailreich und ausgezeichnet aufgelöst klingen lassen können. Und dafür ist ein gutes Referenzdesign nötig. Also vielleicht mal bei den "großen" Chipherstellern nach "Referenzdesign DAC Audio" suchen. Vielleicht findest du da etwas passendes? Wie gesagt - Fertiggeräte/ Platinen liegst du dann garantiert im Bereich mehrerer hundert Euros, Selbst machen wird aber erstens sehr viel Arbeit und Erfahrung benötigen und ob es dann unter dem Strich wirklich "billig" wird!?

Slartibartfas042

Quote from wirbel

Ich glaube du hast in den letzten zwei-drei Jahrzehnten keine Schaltung eines Radios angeschaut. Weder in UKW Radios noch in digitalen Radios werden seit Jahrzehnten Einzel-Transistoren verwendet..

Aber wenn es dir nur darauf ankommt, dann kauf dir doch ein digitales Radio, welches du mit eben den genau gleichen Batterien auch ganz genauso lange laufen lassen kannst. Gibts doch tatsächlich zu kaufen, z.B. eines von Grundig für weniger als 40Euro. Oder von Medion unter 35..

Für DAB+ genügt deutlich weniger Feldstärke am Empfänger. Und falls du es noch nicht bemerkt hast: es sogar für DVB-T2 Innenantennen, und das obwohl die Frequenz nochmal mehr als das doppelte beträgt. Außerdem solltest du deine Argumentation mal um den Unterschied zwischen 'Gleichwellennetz' vs 'Interferenz' erweitern.

Es könnte ja durchaus sein, dass es da noch mehr gibt, was man so zum kompletten Vergleich braucht.

Aber ich halte mich jetzt langsam hier raus.

Macht also keinen Sinn für den nächsten, mich totzubrüllen..

Display More

Ja, du hast Recht, meistens werden diskrete Transistoren - zumindest bei allem oberhalb eines kleinen Radios als Werbegeschenkes - eher nicht mehr verwendet. Bei DAB(+) Radios würde das auch etwas schwierig, bei den einfachen FM-Radios kommen üblicherweise niedrig integrierte analoge IC's mit insgesamt aber sehr wenigen Transistoren zur Verwendung. Wenn du auf Synthesizer Tuner oder gar SDR abzielst - da muß ich dir Recht geben. Bei diesen bist du ja aber auch schon wieder in einer ganz anderen Preisklasse.

Mir ist bekannt, dass du sogar sehr deutlich weniger Feldstärke am Empfänger benötigst. zwar nicht so wenig wie anfangs erwartet, aber durchaus weniger. In sofern hast du da völlig Recht. Der Punkt ist aber doch auch der: Du bekommst - z. B. im Gebäudeinneren - rein von der Wellenausbreitung her bedingt einen sehr deutlich niedrigeren Pegel an der Antenne. Und du hast nicht zwingend in dem relevanten Empfangsbereich einen so viel niedrigeren Rauschteppich, bedingt durch andere Geräte, Datenübertragung, etc. ....

Und natürlich ist ein Gleichwellennetz hilfreich und kann z. B. Überlagerungen durch andere Sendestationen (also anderen Inhaltes) vermeiden. Was es aber nicht verhindern kann ist das im Schnittgebiet auftretende Fading des Antennensignales durch HF-technisches auslöschen der Signalspannungen aufgrund ihrer Laufzeiten. Sprich: Du wirst dort durchaus auch im Gleichwellennetz zwingend eine HF-Interferenz vorfinden welche sich durch die Überlagerung der einzelnen Signalanteile der Sender zustande kommt. Auch wenn ich jetzt mal unrealistischerweise eine 100%ig perfekte Frequenz- und Zeitsynchronisation aller beteiligten Sender voraussetzen würde gibt es im Schnittgebiet kleine Stellen eben im Abstand der Hälfte der Wellenlänge der Hochfrequenz, an denen sich das Signal physikalisch mindestens abschwächt oder im schlimmsten Falle gar auslöscht. Die "Interferenz" auf die du oben abzielst wäre ja vermutlich die Beeinträchtigung durch Nachbarfrequenzen und die daraus resultierenden Überlagerungen mit inhaltlich anderen Sendern. Mal abgesehen davon, dass bei DAB ohnehin nicht jeder "Radiosender" seine eigene Frequenz oder seinen eigenen physikalischen Übertragungskanal hat.

Totbrüllen ist ohnehin nicht meine Absicht, also keine Bange. Mir geht nur die allzu blauäugige Sichtweise in den Medien auf den Wecker, welche bei DAB alles durch die rosarote Brille sieht. Wie du schon schreibst werden immer nur ganz wenige Argumente abgedroschen und gebetsmühlenartig wiederholt, während aber alles offenbar nicht ins Konzept passende noch nicht einmal erwähnt wird.

Slartibartfas042

Quote from Argus

Deine Simu ist und beleibt eine Simu und Theorie. Du machst einen entscheidenden Fehler, Du lässt die ganzen parasitären Komponenten untern Tisch fallen. Sieht ja auf dem Papier ganz nett aus, funktioniert aber leider praktisch nicht so. Für Spule (hier weniger) aber für die Kondensatoren musst Du ins Sheet neben der Kapazität noch den ESR und die Induktivitäten einzeichnen. Dann berechnen, dann siehst Du ein anderes Bild

mein obiges Beispiel bei Pollin kostet nur 4€ , hat exzellente Werte und kommt ohne Löten und Platine basteln aus. Ich selbst würde anstelle des SNT diesen Trafo --> https://www.pollin.de/p/printtrafo-era-bv030-2296-0-300700

plus Greatzbrücke und Elko nehmen, ist absolut sauber und gut.

Auch die Lösung mit dem Trafo ist nur graue Theorie. Ich gebe dir zwar Recht, dass ein längsgeregeltes Netzteil eine saubere Lösung wäre. Was du mit der Low-cost Lösung Trafo/ Zweiwege-Gleichrichtung/ Siebelko aber eliminierst ist der zusätzliche Störnebel durch die Schaltfrequenz des PWM, nicht aber:

Transienten wie sie aus dem Stromnetz üblich sind. Jedes andere Gerät verursacht beim einschalten eine mehr oder weniger große Spannungsschwankung, Schaltnetzteile von Desktoprechnern, TV-Geräten usw. können das Spannungsnetz auch schon belasten, Datenimpulse für Umschaltvorgänge sowohl von der Seite der Stromversorger als auch zu den Endverbrauchern hin sind auch nicht zu verachten. Und natürlich auch schlecht entstörte Endverbraucher wie z. B. große Motoren. Wen's interessiert sucht bei Wikipedia doch einfach mal nach "Rundsteuertechnik"!
Signale und Transienten durch PowerLAN. Auch privat werden Stromleitungen leider mittlerweile häufig zur Datenübertragung vergewaltigt.
Störungen die aus der Spannungsaufbereitung des Raspberry selbst heraus resultieren. Jeder Rechner arbeitet mit möglichst steilen Flanken. Beim schalten dieser Flanken entstehen extrem kurze Spitzenströme in der Schaltung, welche - je nach Layout - durchaus recht nennenswerte Spannungsschwankungen auf den Stromversorgungs-Rails bewirken können. Beschränken sich diese kurzen Impulse und das Rauschen etc. auf den Digitalteil so wird das ohne hörbare Folgen bleiben. Werden diese Signale aber auf den analogen Teil und dessen Stromversorgung "verschleppt" oder übertragen, so wird man das dann schon zumindest messen, vielleicht sogar auch hören können. Je nach Grad der Störung.
Der Raspberry ist ein richtig netter kleiner All-Round-Rechner. Man kann mit ihm schon recht viel anstellen. Allerdings ist dieser "All-Rounder" eben niemals als "Spitzensportler" im Sektor HiFi konzipiert worden! Es kann also immer mal zu leicht verzögerter Datenübermittlung an den DAC, zu leichten Taktvariationen, Phasenrauschen und was-weiß-ich noch alles kommen. Auch auf dem Raspberry selbst sitzen kleine Schaltwandler, welche z. B. die Corespannung der ARM-CPU bereitstellen und somit zu Rückwirkungen auf die Stromversorgung führen.

Also am besten die Kirche im Dorf lassen - wenn du wirklich optimales Analogsignal möchtest solltest du sonst auch selbst an den Anti-Aliasing-Filtern des DAC bei deinem HiFi-Berry DAC(+) optimieren - oder gleich einen richtig guten und sauber arbeitenden/ gefilterten DAC über den SPI ansprechen...

Wer schon einmal mehr oder minder im Blindtest mit exakt der gleichen Audio-CD den direkten Unterschied zwischen einem (Luxman) 18 Bit-Wandler eines teuren CD-Spielers und einem 20 Bit Wandler eines Denon DCD1520 gehört hat (beide damals im Preissegment über 1000,-- DM) wird verstehen worauf ich hinaus will - die Digitaltechnik hört man nicht. Den Wandler - bedingt, ja. Das Anti-Aliasing-Filter oder z. B. höhers Oversampling wird man auf jeden Fall hören können! Aber da steigt der Aufwand exponentiell.

Slartibartfas042

Quote from wirbel

DRM als DAB+ Alternative würde die alte Mittelwelle belegen und 'gute' Qualität in Mono bieten, DRM+ das UKW Band, aber dazu müsste das UKW Band erst einmal frei gemacht werden.

Mal ganz ehrlich - gehts bei dem ganzen Projekt denn wirklich um DRM oder DRM+?

Dafür wäre doch eigentlich Voraussetzung, dass die Sendestationen (also z. B. dein Radio BOB oder was auch immer) ein Interesse daran hätte und das Signal auch für DRM/ DRM+ aufbereitet, nicht? Und das kostet natürlich für das nötige Sende-Equipment oder zumindest für die Dienstleistung des ausstrahlens. Wenn die (privaten) Radiosender ein Interesse an anderen Übertragungswegen hätten, warum haben sie dann die Umstellung auf DAB(+) so schleppend oder gar nicht unterstützt? Sind sie nicht zum Teil heute noch nicht einmal in der Lage ein DAB-Programm zu senden, und das nach mittlerweile knapp 20 Jahren existierendem DAB?

Aus Sicht der Radiosender geht es schlicht und ergreifend um Reichweite (wieviele Hörer kann ich erreichen?) und wieviel muß der Sender dafür investieren? Das Equipment für FM-Ausstrahlung ist bei jedem Rundfunksender definitiv schon vorhanden, es sei denn der "Sender" existiert nur als Internetstream. Equipment für das Einspeisen in ein DAB+- Ensemble oder ähnliches muß dagegen neu angeschafft/ aufgebaut werden. Und auf der Empfängerseite: Ein FM-Kofferradio für 20 Euro (wenige Transistoren/ Dioden nötig, ein bischen Kupferdraht, ein Lautsprecher - Herstellungskosten <<5 Euro!) besitzt heutzutage jedes Kind. Einen DAB(+) Empfänger für 150(+) Euros dagegen vielleicht doch nicht, oder?

Steckt nicht vielleicht ein ganz anderes Interesse hinter dem wieder und wieder Frequenzbereiche und/ oder Empfangsgeräte neu "verkaufen" können???

Slartibartfas042

Quote from wirbel

Mein Gott ist das ein unsinniger Beitrag..

Das eine wie das andre ist einfach Radio. Für beides brauchst du ne Antenne, bei DAB darf die sogar deutlich kleiner ausfallen.

Zur Erinnerung, das sind die 5cm großen 'Haifischflossen'-Antennen am Autodach. Und ein simples MPEG1 Layer2 Audio (aka Musicam oder gar (o gott!)) AAC zu dekodieren kann von der Rechenleistung jeder Winzling wie ein Raspberry.

Zur Antenne: Du weisst aber schon, dass die Haifischflosse sowohl für UKW, DAB und sogar für GSM verwendet wird? Mein Auto hat kein DAB+ Radiogerät, als Antenne wird da aber trotzdem die Haifischflosse verwendet, was ja einfach nur eine Verstärkerantenne ist.

Und der Unterschied zwischen Raspberry und 10 Transistoren zum demodulieren von FM? Wie viele Tage lang kannst du einen Raspberry aus einem Satz von 4 Mignonzellen betreiben?

Nein, ich glaube die Diskussion über die Schiene "Informationsverbreitung im Notfall" führt zu nichts, die Aera der "Cover-and-Duck" Anweisungen und "im Ernstfall einfach unter dem Tisch in Deckung gehen" Anweisungen ist wohl hoffentlich auch allmählich zu Ende. Da gibt es aber Punkte, die ich in den ganzen Diskussionen nicht wirklich sehe und von denen ich aber glaube dass sie durchaus Sinn machen:

1) Radio läuft "nebenher", d. h. es soll nicht von der eigentlichen Tätigkeit ablenken. Was nützen dann also Zusatzdienste wie eine Anzeige des Liedtitels oder z. B. Scrollende Informationen über Sendertelefonnummern?

2) FM wird im 100 MHz Bereich übertragen, da ist die Dämpfung einer normalen (Ziegel-) Mauer eher kein so großes Problem. Digitales Radio findet bei Frequenzen ab ca. 170 MHz aufwärts statt. Mit steigender Frequenz steigt auch die Beeinflussung durch Mauerwerk. Während UKW-Radio also mit Teleskopantenne im Innenraum problemlos möglich ist ist für DAB(+)-Empfang im Innenraum mit Teleskopantenne hier überproportional viel Signal im Außenbereich nötig. War nicht gerade der große Vorteil von DAB gegenüber FM die deutlich verringerte Sendeleistung??? Ähhh....

Slartibartfas042

Problem: Habe ein "etwas größeres" Setup am Start und möchte da eigentlich ca. 50-60 (Radio-) Streams parallel über die Schnittstelle Streamdev-Server ausspielen. Leider gehen maximal 26 Streams parallel. Hat irgendwer eine Idee woran genau diese Beschränkung liegen könnte? Ich kann leider keine Hinweise finden.

Verwendete Hardware:

akutelles Serverboard SuperMicro
TBS Octa-Tunerkarte für DVB-C oder bisher auch schon 2 TBS Quad-Tunerkarten, gleicher Effekt

Verwendete Software:

vdr (2.2.0/2.3.9) - The Video Disk Recorder

streamdev-server (0.6.1-git) - VDR Streaming Server

Bei den immer wieder abgelehnten Streams scheint es egal zu sein, auf welchem Transponder diese liegen. Auch Transponder, welche bereits von anderen Streams verwendet werden (und somit vom Tuner her zur Verfügung stehen!) sind von den Abwürfen betroffen, es handelt sich also scheinbar um ein Problem mit der blanken Anzahl an Puffern(?) oder etwas ähnlichem.

Bisher testweise schon mal geänderte Variablen im Source-Code:

in vdr-2.3.9/device.h (die Werte habe ich einfach mal testweise willkürlich auf 500/1000 hochgesetzt)

#define MAXDEVICES 500 // the maximum number of devices in the system (war vorher 16)

#define MAXPIDHANDLES 1000 // the maximum number of different PIDs per device (war vorher 64)

#define MAXRECEIVERS 500 // the maximum number of receivers per device (war vorher 16)

gehe ich recht in der Annahme, dass das "Device" die Karte wäre und mit Receiver dann die dieser Karte zugehörigen HF-Tuner gemeint sind? Wäre dann bei einer 8fach-Tunerkarte im Gerät 1 Device und 8 Receivers?

im Plugin-Verzeichnis vom Streamdev geändert:PLUGINS/src/streamdev/server/setup.c:

MaxClients = 500;

Im Log zu findende Hinweise die mich aber bisher noch nicht wirklich zum Ziel geführt haben:

Apr 12 11:22:29 myhost vdr: [28995] Streamdev: Accepted new client (HTTP) 127.0.0.1:54460

Apr 12 11:22:29 myhost vdr: [28995] Streamdev: Accepted new client (HTTP) 127.0.0.1:54456

Apr 12 11:22:29 myhost vdr: [28995] Streamdev: Accepted new client (HTTP) 127.0.0.1:54458