VLC findet den FritzBox-Mediaserver nicht

Photor

Well-Known Member
Hallo Forum

kein essenzielles Problem, aber ich wüsste gerne, warum es nicht tut.

Meine FritzBox spielt auch Mediaserver im Heimnetz, was auch funktioniert - zumindest unter Linux und für IOS-Geräte; der Server wird gefunden, gelistet und ich kann die Musik abspielen. Das tut also, wie es soll.

Unter FreeBSD (12.2) ist ebenfalls VLC instaliert und lokale Mediendateien kann ich abspielen. Allein der Mediasever taucht nicht auf. Ich habe schon gesucht, ob ich irgendwo was einstellen muss: finde jedoch keinen Grund dafür. Ich gehe davon aus, dass ich einfach noch nicht die richtige Stelle gefunden habe. Kann mich jemand hier mit der Nase drauf stupsen?

Ciao,
Photor
 
Hallo @Rosendoktor,

Ah (ich hatte mir fast(TM) sowas gedacht - deshalb die Frage hier; ich muss noch viel lernen). Danke. Das kann/werde ich mal probieren.

Gibt es einen Grund dafür, das Protokoll nicht direkt mit einzucompilieren?

Danke,
Photor
 
Beim VLC geht's ja noch. Aber wehe Du brauchst das Datenbankfeature bei LibreOffice, das gibt bei jedem Update eine Compilierorgie... :ugly:
 
Gibt es einen Grund dafür, das Protokoll nicht direkt mit einzucompilieren?
gibt es einen Grund dafür, solche Protokolle überhaupt nutzen zu wollen?
Du kennst den Spruch: "jeder unerwünschter Service ist nur eine weitere Belästigung"?
Man könnte leicht seinen Rechner/Hausnetz mit dutzenden von Diensten überschwemmen, die sich unterschiedliche Entwickler mal ausgedacht haben, um irgendwas möglichst einfach und automatisch los zu treten. Mich gruselt es immer, wenn irgendwas automatisch passiert. Es fühlt sich an, als würde ich da bevormundet. Jemand weiß ja sooo genau, was ich haben möchte und womit man mich glücklich machen kann...
Deshalb bin ich froh, dass das mit FreeBSD (noch) nicht so ist und ich glaube ein wenig (weiß das aber nicht), dass es ein Grund für die relativ gute Performance meiner FreeBSD-Desktop-Systeme im Vergleich zu etwa Windows10 ist. Wenn ich sehe, was bei Freunden und Kollegen alles so läuft und welche Dinge da laufend aufpoppen (und eigentlich doch nur effektives Arbeiten stören), müssen da ja wohl auch gewisse Systemressourcen für diese "Zusatzleistungen" verbraucht werden.
 
gibt es einen Grund dafür, solche Protokolle überhaupt nutzen zu wollen?
Weil "man" Service Discovery haben möchte. Sprich: Man möchte Wissen, welche Services im LAN es überhaupt gibt. Damit man da nicht irgendwo irgendwas per Hand zusammensuchen und eintragen muss.

Mich gruselt es immer, wenn irgendwas automatisch passiert.
Heutzutage geht aber sehr sehr viel automatisch. Also auch unter angeblich minimalistischen Systemen. Wenn man so überlegt, wieviel man noch vor einigen Jahrzehnten manuell konfigurieren musste.
An vieles denkt man gar nicht mehr, weils selbstverständlich geworden ist. Wie z.B. ein dynamisches /dev , Plug&Play Hardware ohne "Mäuseklavier" oder (um mal beim Thema Netzwerk zu bleiben) sowas wie DHCP.

Wer sich die ganzen Automatismen weg wünscht der sollte mal als Realitätsabgleich irgendein UNIX von Anfang der 90er Jahre installieren. :-)
 
Moin,

Nachtrag: cd /usr/ports/multimedia/vlc, make configure (mit Aktivierung von UPNP), make package, make install, make clean hat funktioniert: VLC sieht den Mediaserver jetzt - ungeachtet, ob das jetzt wünschenswert oder sinnvoll oder ... ist. Da werde ich vielleicht nochmal drüber nachdenken. Erstmal habe ich wieder was, was funktioniert. Gut so.

Über den Mix aus Ports und Packages muss ich nochmal nachdenken. Da wurde doch einiges als Abhängigkeit installiert.

Danke für die Hilfe,
Photor
 
Vielleicht solltest du auch mal beim Maintainer nachfragen, warum die Funktion deaktiviert wurde. Oft denkt man als Maintainer dann noch mal drüber nach und sieht es dann als sinnvoll an, eine bisher deaktivierte Funktion doch standardmäßig einzuschalten, weil es einfach benutzerfreundlicher ist.

In dem Fall ist der Maintainer das Multimedia-Team (multimedia@FreeBSD.org)
 
Moin,

Umstieg auf FreeBSD 13 (nach zerschossenem bootloader neu installiert - eigene Dummheit): also den VLC wieder aus den Ports compiliert und installiert (make package, make install). Dabei werden einige Pakete als Abhängigkeit mit compiliert (z.B. Python-3.8 statt Python-3.7 aus den Packages - Python-Versionen können ja auch nebeneinander leben). Gut soweit: der VLC erkennt den UPNP-Mediaserver der FritzBox.

Aber: jetzt routinemäßig pkg upgrade gemacht und da wird VLC geupdatet wg unterschiedlicher Optionen (warum nur :)). Erfolg: VLC ist wieder ohne UPNP unterwegs.

Also meine Frage: wie komme ich aus dem Widerspruch am BSD-konformsten raus? Im Handbuch steht, dass man Packages und Port nicht mischen soll; ist beides nebeneinander also nicht möglich?

Ciao,
Photor
 
Moin,

iirc: "pkg lock vlc".

Ok. das war etwas knapp. Deswegen ausführlicher: Packages und Ports lassen sich dem Grunde nach schon mischen, wenn man ein paar Dinge berücksichtigt. Dein Vorhaben lässt sich vermutlich (ich habe es noch nicht benötigt) durch "locken" des installierten Ports erreichen. Allerdings solltest du @lme 's Tipp beherzigen. Wenn der Maintainer Einsicht hat, kannst du auch für vlc Packages nutzen.

HTH :)
 
Also meine Frage: wie komme ich aus dem Widerspruch am BSD-konformsten raus? Im Handbuch steht, dass man Packages und Port nicht mischen soll; ist beides nebeneinander also nicht möglich?

Ciao,
Photor
Doch, solange Du weißt was Du tust und es Dir merkst. Also das Paket wie @Columbo0815 schrieb mit pkg lock vlc sperren, dann wird es nicht mehr aktualisiert. Dann bekommst Du natürlich auch echte Updates des Pakets nicht mehr. Also gelegentlich checken, ob Deine gesperrten Pakete noch aktuell sind. Die Liste der gesperrten Pakete kannst Du mit pkg lock --show-locked abfragen.

Früher, das war glaub ich noch 10.x oder 11.x, hatte ich mal nach einem pkg upgrade Probleme bekommen, weil Bibliotheken aktualisiert wurden die von einem gesperrten Paket genutzt wurden und dann nicht mehr kompatibel waren. Ob das immer noch passieren kann weiß ich nicht. Also, falls seltsame Dinge passieren nach einem Upgrade, immer auch an evtl. gesperrte Pakete denken und das checken.
 
Im Handbuch steht, dass man Packages und Port nicht mischen soll; ist beides nebeneinander also nicht möglich?
Doch. Ist es. Insbesondere wenn Du Dich aus dem latest-Repository bedienst. Das ist nämlich weitestgehend auf den Stand der Ports.
Du kannst auch mit make package aus dem Port direkt ein Package erstellen. Das liegt dann als Datei unter
work/pkg/paketname.txz
Und Du kannst es via pkg add paketname.txz entsprechend installieren.
 
pkg lock ist ja die Antwort.
Aber, ich habe das lange Zeit so mit einigen, wenigen Ports gemacht und dann gelernt, dass doch hin und wieder die Abhängigkeiten verrutschen und die ein oder andere Funktion nicht mehr ging.
Deshalb hatte ich mir angewöhnt, nach jedem pkg upgrade (was ich nicht zu oft mache), die Ports einfach neu zu bauen. Bei zwei drei Ports ist das ja schnell passiert und kein Ding.
 
Ok. Vielen Dank allen für die Antworten! Ich kämpfe mich mal in das Thema weiter rein, aber lock mir scheint erstmal das richtige; hab nicht vor, viele Ports zu nutzen; Packages sind halt bequemer.

ciao,
photor
 
Bau deine Ports über "poudriere". Dann kannst du das erstellte Repo zusätzlich einbinden und hast ein sauberes System und du kannst die Pakete auch auf weiteren Rechnern problemlos installieren.
 
Bau deine Ports über "poudriere". Dann kannst du das erstellte Repo zusätzlich einbinden und hast ein sauberes System und du kannst die Pakete auch auf weiteren Rechnern problemlos installieren.
Oha. Da bin ich schonmal drüber gestolpert, habe aber immer gedacht, dass das für einen Laptop (reines Test-System) Overkill ist. Aber ok. Ich schau mir das mal im Handbuch an.

Ciao,
Photor
 
Wer sich die ganzen Automatismen weg wünscht der sollte mal als Realitätsabgleich irgendein UNIX von Anfang der 90er Jahre installieren. :-)

tja, in Massen ja... Ich erinnere mich vor vielen Jahren an ein Solaris Upgrade, da kamen viel Automatismen hinein und jede Konfiguration die ich mühsam in die Textdateien geschrieben habe, war nach der Installation weg. Als ich es dann realisierte, wie es ging, war es okay. Aber um ehrlich zu sein, es hat meine Arbeit nicht erleichtert... Auf der andern Seite ist es gut, Automatismen zu haben. Sowohl im Computer als auch an unserem Körper. Wenn ich die Verdauung willentlich kontrollieren müsste - das gäbe bestimmt ein riesen Durcheinander ;-) VG Norbert
 
Ok. Vielen Dank allen für die Antworten! Ich kämpfe mich mal in das Thema weiter rein, aber lock mir scheint erstmal das richtige; hab nicht vor, viele Ports zu nutzen; Packages sind halt bequemer.

Das heißt in Konsequenz aber auch, dass die Sicherheitslücken in VLC nicht durch automatische Aktualisierungen behoben werden?! :confused:

Aber um ehrlich zu sein, es hat meine Arbeit nicht erleichtert.

Je nach Zeitpunkt der Aktion ging Solaris vielleicht schon davon aus, dass die händische Serverkonfiguration eine Anomalie ist und sowieso jeder seine Server via Puppet & Co. konfiguriert.

Auf der andern Seite ist es gut, Automatismen zu haben.

Die besten Unternehmen, die mir diesbezüglich begegnet sind, haben eine "terminate after logout"-Policy. Nachdem sich jemand zu Diagnosezwecken per SSH auf einer Maschine eingeloggt hat, wird die beim Logout automatisch geplättet und neu installiert bzw. provisiert, damit jegliche betriebsrelevante Konfiguration und Änderung in git hinterlegt und nachvollziehbar ist. :cool:
 
Klar. Das ist wie bei anderen OSen auch: wenn ein Paket auf „on-hold“ gesetzt ist … ich werde ein Auge drauf haben.

Ciao,
Photor
 
Also bitte!
Wenn es hier nur um einen Port geht oder um zwei oder drei oder so, ist die Aufregung doch zu groß, oder?
Einfach Pakete nutzen und dort, wo es nicht passt, den Port mit abweichenden Optionen bauen und gut ist.
Wir reden hier nicht über einen Server, der immer 100% sicher laufen soll.
Als Desktop-Nutzer stolpert man doch dauernd über Probleme mit dieser oder jener SW, ganz egal, ob die nun aus Paketen oder Ports stammt.

Entweder, du überredest die Maintainer, die Optionen zu ändern, oder du baust das eben selbst mit deinen gewünschten Optionen.
Daraus erseht keine messbare Gefahr für dein System und es ist auch manuell gut zu handeln, wenn es eben nur wenige Ausnahmen sind und nicht das halbe System durchmischt wird.
 
Wir reden hier nicht über einen Server, der immer 100% sicher laufen soll.

Gerade VLC ist ein beträchtliches Einfallstor: VLC Vulnerability Statistics

Es gab bei VLC mehr als eine Sicherheitslücke, bei der das Abspielen einer manipulierten Datei (bzw. der Aufruf eines manipulierten Links) ausgereicht hat, damit der Angreifer beliebigen Code mit deinen Berechtigungen ausführen konnte. In Anbetracht dessen würde ich bei VLC eine gewisse Vorsicht walten lassen.
 
Zurück
Oben