Kodi!? (3 Viewers)

[radical]

Gerade mit Laufwerksbuchstaben habe ich früher häufig erlebt, dass diese nach einem Neustart in Mediaportal nicht verfügbar waren. Darum bin ich erst auf UNC Pfade umgestiegen.
Kann natürlich sein, dass sich in der Zwischenzeit was geändert hat und MP mittlerweile besser mit klarkommt.

 

[HTPCSourcer]

Um zu vermeiden, dass die Diskussion an dieser Stelle erneut auflebt: In Area 51 wird in Kürze eine Testversion aufgelegt, in der die Netzwerk-Shares anders gehandhabt werden, so dass keine großen Verzögerungen mehr auftreten. Also dort mal gelegentlich nachschauen und testen

 

[resa]

@radical

Naja, manchmal dauert es halt, bis Windows Netzwerklaufwerke wieder verbunden hat, auch wenn das Laufwerk im Windows Explorer zu sehen ist, ist es dann natürlich kein valides Laufwerk beim Zugriff, mag sein, das das Laufwerk deshalb in MePo zunächst nicht als verfügbar erkannt wird, wenn MePo zu schnell startet... wird es aber spätestens wenn man wieder drauf zugreift, sobald Windows es verbunden hat.... Und natürlich ... damit Windows das Laufwerk überhaupt nach einem Neustart wieder einbindet, muss man den entsprechenden Haken unter dem Feld für den Netzwerkpfad setzen, bzw. im cmd den Parameter /persistent benutzen, ist ja klar...

Letztlich ist aber der Trick genau der, das das Laufwerk beim starten von MePo eben nicht verfügbar sein soll... damit umgeht man grundsätzlich auch alle rödeleien, die MePo ggf. gleich beim Start auf das Laufwerk ausführen möchte, z.B. das evtl. scannen nach neuen Files von MovPic oder TV-Series etc. pp., das pingen und suchen passiert sowieso nur wenn man in MePo direkt netshares verwendet...

Weiter vorne hat jemand im spoiler ein log davon gepostet, wo MePo nach tausend Shares in der art wie //sowieso/sowieso A/filme, //sowieso/sowieso B/filme usw. usf. gepingt und gesucht hat... stattdessen bindet man 1 Netzwerklaufwerk auf //sowieso/ z.B. als Z: ein, und setzt dann die einzelnen Ordner in den MePo Settings als Z:/sowieso A/Filme, Z:/sowieso B/filme ...

Um damit wirklich jegliche Komplikationen auszuräumen, kann man dann auch das Wiederverbinden/persistent weg lassen und statt dessen entweder in MePo einen Menu-Punkt für die manuelle Ausführung einer Batch einbauen, die mit net use Z: //sowieso/ das laufwerk erst bei bedarf einbindet... oder aber man startet MePo eben direkt mit einer Batch, die dann MePo startet und 2 minuten später mit net use das Laufwerk verbindet...

Der Clou ist: So kann man sogar trotzdem mit dem hochfahren den share für andere aufgaben aus dem Windows heraus benutzen, MePo reagiert auf das Laufwerk aber erst, sobald der Buchstabe auch zugeteilt wurde...

Braucht man den share aber schon als Laufwerk mit Buchstabe beim hochfahren aus dem Windows heraus, dann kann man das Netzlaufwerk eben zum Wiederverbinden/persistent einrichten und benutzt zusätzlich ein alias mit einem weiteren Laufwerksbuchstaben bzw, einen weiteres Netzlaufwerk einen Ordner tiefer, also net use oder subst... muss man evtl. noch eine Ordnerebene dazwischenfügen... also z.b. statt //sowieso/sowieso A/filme dann //sowieso/data/sowieso A/filme... dann setzt man Netzwerklaufwerk persistent Z: auf //sowieso/, dazu in den eben genannten Batches Alias-Laufwerk X: mit subst oder net-use auf Z:/data/... und benutzt als Ordner in den MePo-Settings dann eben wieder X:/sowieso A/filme....

Und so weiter und so fort bis zum abwinken...

Ich seh echt das Problem mit alledem nicht, ist ja nicht böse gemeint

Edit: @HTPCSourcer ...

Mir liegt es fern einen Streit vom Zaun zu brechen, ich wollte nur verstehen, wo das Problem eigentlich hier liegt? Kann ja sein, das ich was überlesen hab, trotz gewissenhaften lesen aller Posts, warum man jetzt ganz zwingend auf die netshares angewiesen wäre, wenn man die Laufwerke quasi wie ein USB-Laufwerk nur bei Bedarf hinzuschalten möchte.

Im übrigen hatte ich schon versucht auf den Link zu einem weiterführenden/besser passenden Thread in einem früheren Post zuzugreifen, worauf mir das Forum mitteilte, das ich darauf kein Zugriff hätte?! Wollte also nicht rein mutwillig diesen Thread hier dazu missbrauchen, ich seh ja, das es knapp am Topic vorbei geht... Ich hoffe, es sei mir verziehen

MfG

 

[radical]

Es ging hier auch nicht darum ob der UNC-Pfad sinnvoller ist als den Pfad über ein Netzlaufwerk einzubinden, sondern wie sich Mediaportal verhält wenn beides nicht verfügbar ist.

Zum Thema UNC-Pfad vs. eingebundenes Laufwerk:
Vielleicht missverstehe ich deine Erläuterung oder wir reden aneinander vorbei, aber gerade wenn ich UNC Pfade nutze, umgehe ich doch die Problematik der nicht verfügbaren eingebundenen Netzlaufwerke.

Eine "netuse"-Batch nutze ich bereits als Aufgabe beim starten. Stoße aber regelmäßig auf den Systemfehler 1219.
Nach meiner Erfahrung würden dadurch, sofern ich auf eingebundene Netzlaufwerke in MP verweise, meine Medien in Mediaportal nicht mehr verfügbar sein.

Um das nochmal als Beispiel zu verdeutlichen:

Der Pfad '\\Server\Filme' ist bei mir immer verfügbar (außer der Server antwortet gar nicht aus irgendwelchen Gründen, dann würde aber netuse auch ins leere führen)

Wenn ich jetzt die Freigabe als Netzlaufwerk mit einem Buchstaben einbinde und auf diesen in MP verweise, muss ich drauf hoffen, dass Windows beim starten das Netzlaufwerk auch sauber einbindet. Dies funktioniert bei mir jedoch nicht immer zuverlässig sondern endet öfters in o. g. Fehler.
Oder hat sich an dem Verhalten von MP mit eingebundenen Laufwerken mittlerweile etwas geändert?

@HTPCSourcer

Entschuldige bitte das offtopic. Es kann auch gerne von einem Mod in einen separaten Thread verschoben werden.

 

[HTPCSourcer]

@HTPCSourcer
Entschuldige bitte das offtopic. Es kann auch gerne von einem Mod in einen separaten Thread verschoben werden.

Steht euch frei: Aber noch einmal - das Problem ist bereits gelöst und die Diskussion hat deshalb keine Grundlage...

 

[resa]

@HTPCSourcer : Das es für das Problem eine Lösung seitens des developement gibt hatte ich ja schon mitbekommen. Mir ging es darum das eigentliche Problem hier einzugrenzen, da ich mitunter Leute mit MePo betreue, die - never touch an running system - eben nicht immer das aktuellste MePo fahren und ich dann gerne wüsste wonach ich zu suchen hätte, wenn ich mich in meiner Annahme irre, das die hier genannten Probleme Konfigurations-bedingt und selbst indiziert sind. Letztlich habe ich aber nun zuerst alles geprüft um eine zu ausladende Diskussion zu vermeiden und bin mir sicher in dem, das so wie ich es handhabe und auch weitergegeben habe, solche Probleme tatsächlich gar nicht erst auftreten. Ich möchte nur noch mal auf radical's letzten Post eingehen, um seinen Bemühungen mir zu antworten mit dem selben Respekt zu begegnen

@radical :

Ja, wir reden wohl ein wenig aneinander vorbei, denn das Problem was hier angesprochen wurde und auf das ich mich bezog, ist die lange Startzeit von MePo1in Verbindung mit bewusst und gewollt nicht erreichbaren Lokationen im Netzwerk, da diese eben nicht vom MePo-Start geweckt, sondern so lange weiter schlafen sollen, bis wirklich Medien davon abgerufen werden.

In sofern muss ich sagen: Nein, es geht (mir) im gegenteil grad eben genau darum, ob hier nun ein Netzwerkpfad oder Netzwerklaufwerk sinnvoller wäre. Aufgrund einer ganz anderen Überlegung - nämlich eine Lokation im Netzwerk frei verschieben zu können, ohne im MePo auch nur einen Handschlag tätigen zu müssen - habe ich mich schon von Anfang an für Netzwerklaufwerke entschieden. Hänge ich z.B. eine Platte von einem Server in den anderen, also von \\Server1\PlatteXYZ nach \\Server2\PlatteXYZ, dann brauche ich, wenn ich die Lokation \\Server1\PlatteXYZ als Laufwerk Z: im Windows und im MePo als Medienquell-Ordner Z: statt des Netzwerkpfades angegeben habe, nur das Laufwerk Z: im Windows zu trennen und dann denn Netzwerkpfad \\Server2\PlatteXYZ als Z: neu zu verbinden. Ergebnis ist, das es für MePo so ausschaut, als hätte sich absolut nichts verändert.

Damit nicht genug: Stellt man im MePo einen Laufwerksbuchstaben (oder auch einzelne Unterordner dieses Laufwerks) als Medienquell-Ordner statt Netzwerkpfade ein, dann behandelt MePo dies im falle der unerreichbarkeit genauso wie ein nicht angeschlossenes USB-Laufwerk, das im MePo als Medienquelle angegeben wurde, d.h. alle Aktionen die sich auf dieses Laufwerk beziehen, werden - nicht nur beim starten von MePo - ohne zeitliche Verzögerung einfach kommentarlos übergangen <- Genau das ist, worauf ich hinaus wollte.

Mit einem Netzwerkpfad, der sich quasi im OS-Usermode frei von MePo benutzen lässt und MePo sogar erst noch dazu einlädt, sofern nicht sofort im DNS/LLMNR-Cache des Rechners zu finden, über die Anwendungsschicht des TCP/IP-Modells ewigkeiten danach zu pingen, zu suchen, MagicPakets zu schicken und eine vom User selbst eingestellte Zeit abzuwarten, ob das Ding nun endlich mal hochkommt... braucht man sich nicht zu wundern, das MePo ewigkeiten den Splashscreen darbietet, bis das alles abgegrast ist.

Mit einem Netzwerklaufwerk, das den Netzwerkpfad quasi in den OS-Kernelmode verschiebt, kann MePo nur eins machen, nämlich in der Windows mountlist gucken, ob dieses Laufwerk gerade da ist oder nicht. Wenn ja, werden unverzüglich die gewünschten Aktionen auf dem Laufwerk abgefahren, wenn nein, werden alle anstehenden Aktionen für dieses Laufwerk unverzüglich abgebrochen und übergangen. Ende der Geschichte. Mehr kann MePo dann nicht machen, da gibt es nichts mehr zu suchen oder abzuwarten.

Und es spielt überhaupt keine Geige ob das Laufwerk beim starten von MePo schon fertig von Windows verbunden wurde oder nicht, aktiviert man die Checkbox für das automatische Wiederverbinden beim Windows-Start, wird es stets fertig eingebunden (solange der Host überhaupt erreichbar), auch wenn das direkt zum Start von MePo noch nicht abgeschlossen ist, so steht das Laufwerk dann einige Augenblicke später im MePo definitiv zur Verfügung und ist dann auch ohne Einschränkungen nutzbar. Allerdings erzwingt dies, je nach Fähigkeiten des Hosts, an dem das betreffende Laufwerk hängt, mitunter das anlaufen der entfernten Platten schon durch den Windows-Verbdindungsversuch, möchte man dies nicht, versetzt man den kompletten Host in den WoL-Schlaf, womit das Netzwerklaufwerk solange im Windows getrennt und in MePo nicht verfügbar bleibt, bis der Host mit WoL geweckt wurde, dies macht Windows nämlich nicht automatisch beim Verbindungsversuch. Wurde der Host dann geweckt und sind die Platten angelaufen, dann wird spätestens mit dem ersten gezielten Zugriff, z.B. das starten eines Videos, ein erneuter Verbindungsversuch ausgelöst und das Laufwerk innerhalb weniger Sekunden aktiv in die mountlist eingetragen, mag ggf. sein, das man also beim ersten Zugriff dann 2 mal probieren muss, damit das Video dann aus MePo heraus startet. Ansonsten wird ein nachträglich geweckter Host aber auch automatisch alle paar Minuten vom Windows erkannt und darauf befindliche Netzwerklaufwerke nachträglich verbunden.

Gibt es damit Probleme, liegt ein generelles Defizit bezüglich der Netzwerkkonfiguration zu Grunde, sprich die Windows-PCs, andere Rechner, NASes oder auch der Router ist für eine Reibungslose Funktion nicht richtig konfiguriert. Punkt.

Wenn mann nun also wünscht, das bestimmte Lokationen beim start von MePo weder anlaufen, noch das von MePo danach gesucht wird, schickt man einfach nur den Host schlafen und lässt diese als Netzwerklaufwerk automatisch wiederverbinden, was erst klappen wird, wenn der Host geweckt wurde oder im absoluten Zweifel lässt man nicht automatisch von Windows wiederverbinden, sondern optimiert diesen Vorgang für das eigene Setup mittels einfacher batches, net use und ggf. auch WoL für den gewünschten Zeitpunkt, für komplizierteste und bequemste Setups kann man auch weitere Windows-Boardmittel wie subst oder eben weitere externe Befehlszeilentools hinzunehmen. Man darf nicht erwarten, das ein Setup aus Windows, OpenSource und sonst. Consumer-Geräten mit einer Konfiguration aus weitestgehenden Factory-Defaults, die dem breiten Bedarf an einfachen Konstellationen entsprechend ausfällt, aufwendigste Netzwerkadministrative Szenarien abbildet, ohne sich mal tiefgehend mit alledem auseinander zu setzen.

Um da jetzt noch einen drauf zu setzen: Da ich nicht mal die teils hier zitierten MePo-Logeinträge mit Netzwerkpfaden als Medienquell-Ordner im MePo und darauf aktiviertem WoL (BTW lassen sich dann unter WoL-Parameter im MePo-Config dann auch die Wartezeiten eingrenzen etc. - bei der Verwendung von MagicPaket braucht man nicht unbedingt darauf warten, wenn man eh nix gescheites im Moment des MePo-Starts davon will) in dieser Form reproduzieren konnte, geh ich mittlerweile davon aus, das es sich bei den Verursachern der langen Startzeiten um generelle Denkfehler oder "exotischere" Plugins handelt, die schlicht nicht richtig konfiguriert wurden oder gar nicht passend konfiguriert werden können, um die gewünschten Ergebnisse zu erzielen. Keine Ahnung ob das Irgendwelche Powermanager/WoL-Plugins sind, jedoch weder MyVideos, noch MovingPictures, noch MP-TV-Series verursachen derart exorbitante Delays beim MePo1 Startup, definitiv nicht bei der Verwendung von unverbundenen Netzwerklaufwerken, aber auch nicht so wirklich bei der Verwendung von Netzwerkpfaden, ansonsten käme eigentlich nur noch LMH als Auslöser unter den gängigeren Plugins in Frage, die ich hier grad nicht benutze. Meine abschliessende Einschätzung ist also nunmehr: das @HTPCSourcer vollkommen recht hatte, mit all seinen Einschätzungen und Einlassungen und hier dann gegen enorme Windmühlen argumentiert hat, um für mehr Eigeninitiative zu werben, sich für die komplizierteren Eigen-Konstellationen mit der nicht ganz perfekten Umsetzung/fehlenden Konfigurationsmöglichkeiten/fehlender Offensichtlichkeit der Netzwerkbelange in MePo1 auch mal eigene workarounds zu überlegen

Etwas unglücklich an der Diskussion finde ich, das das ganze in einer wehementen Grundsätzlichkeit einzig auf MePo1 geblamed wurde, obwohl zum guten Teil wohl auch eher mal Faulheit als Grund in betracht kommen wird, legt man mal wieder kostenlose OpenSource als Umrechnungskurs zu Grunde Das gute ist, das jetzt natürlich eine Developerseitige Lösung herbei gemosert wurde, womit wohl auch MePo1 weit komplexere Szenarien viel einfacher unterstützen wird, als es je eine kommerzielle Software tat oder tun wird und womit die langfristige Berechtigung und Nachfrage für ein fortgesetztes MePo1-Developement weiter zementiert wird. Tripple Knieshot für alle, die hier versuchen, möglichst viele der Developer-Stunden gewaltsam Richtung MePo2 umzudiskutiueren... muharharhar

(Kleiner Scherz )

So, bevor sich jemand beim vorbei lesen oben fragt, wie man USB-Laufwerke gescheit als Medienquelle verwenden kann, wenn man diese auch noch abschaltet...Ja, geht Prima... man kürt für jedes Laufwerk einen bestimmten Buchstaben, den dieses Laufwerk und nur dieses Laufwerk für immer haben soll.. beim ersten Anschließen wird wie gewohnt der erste freie Buchstabe von unten vergeben.... dann geht man einmal in die Verwaltung/Datenträgerverwaltung... aktuellen Laufwerksbuchstabe entfernen, danach den künftig gewünschten Laufwerksbuchstaben hinzufügen... Fertig, Windows wird künftig diesen Laufwerksbuchstaben vergeben, egal ob dann davor Buchstaben frei bleiben würden....

Dann abschließend noch die Auflösung bezüglich des "Systemfehler 1219" bei der Verwendung von net use für radical...: verstehe zwar nicht so ganz, wie es damit ein beständiges Problem geben kann... eine kurze googelei offenbart doch ganz deutlich und Seitenweise, woran es aller-höchstwahrscheinlich hapert, wenn dieser Fehler geworfen wird... mit net use verbundene Laufwerke müssen immer vom selben User verbunden werden, oder aber man trennt das Laufwerk mit net use, bevor ein anderer User das selbe Laufwerk neu verbindet... Das übersieht man schnell, je nach dem, wie der Befehl beim Systemstart verwendet wird und wurde, oder es reicht auch mal eine als Administrator geöffnete Eingabeaufforderung... und schwupp wurde das Laufwerk mal unbemerkt von einem ganz anderen User verbunden... Abhilfe: mit allen in Frage kommenden Usern das Laufwerk mittels net use trennen... und dann darauf achten, das das Laufwerk künftig immer vom selben User verbunden oder aber vor dem Userwechsel automatisch getrennt wird o.ä.

Ganz umgehen kann man das Problem, indem man net use EINMALIG mit der Option /persitent unter dem gewünschten Useraccount verwendet, anstatt diesen immer wieder erneut beim Windows-Startup auszuführen... mir erschliesst sich jedenfalls so noch nicht, warum das jedesmal erneut beim Windows-Start notwendig ist, aber mag ja sein, das da noch weiteres wie WoL o.ä. ausgelöst wird... Wenn nicht, wie schon oben gesagt: Das Laufwerk wird dann schon irgendwann einen Moment später verfügbar sein mit /persistent resp. dem Haken bei automatisch Wiederverbinden über die GUI, bzw. wird auch später noch Verbunden, wenn der Host im Netz wieder verfügbar ist (letzteres kann nur einige Minuten dauern, bis Windows den Host gesehen hat, kann man abkürzen indem erst einmal zugegriffen wird, beim zweiten Zugriffsversuch ists dann verbunden).

So hoffe das war jetzt alles verständlich und umfassend genug ausgeführt, warum, wieso weshalb ich überhaupt in diese Richtung gestochen habe. Es möge sich bitte auch niemand angegriffen fühlen dadurch, wenn es so klang/klingt, war/ist dies unbeabsichtigt, wollte das ganze für mich zum Verständnis nur nachhaltig abklären. Wenn das jemand stört/e bitte ich um Nachsicht Wenn noch Fragen sind, steh ich gerne noch per PN Rede und Antwort, hier im Thread belasse ich es jetzt mal lieber hierbei.

Danke für eure Antworten, Sorry und nix für ungut sowie MfG

P.S. und Edit: Wer sich natürlich von ewigen Bubbleblasen nebst Symbolik nahe der Taskleisten-Uhr "Es konnten nicht alle Netzwerklaufwerke wiederhergestellt werden" oder an irgendwelchen ewig währenden kleinen roten "x"-Symbolen an Laufwerken im WindowsExplorer orientiert und sich deswegen davon abhalten lässt, Netzwerklaufwerk trotzdem einfach zu verwenden, um zu merken, das die schon lange im korrekt im System verfügbar ist, dem sei angeraten, sich mal folgendes klar zu machen:

Bezüglich jeglicher Netzwerkressourcen sollte man sich NIE gänzlich und allein auf die Symbolik, die Meldungen und im Zweifel auch nicht auf das korrektes/logisches/nachvollziehbares funktionieren/reagieren/verhalten der Windows-GUI verlassen, WENN das Netzwerk und alle Ressourcen darin NICHT von einem ordentlich konfigurierten Windows Domänen Controller verwaltet werden.

So einfach ist die Sache eigentlich

Also im Prinzip rutscht man ohne Windows-Server und nur mit Windows-Desktoprechner und dazu zusammen gewürfelten sonstigen Geräten im LAN genauso schnell in die notwendige Benutzung der Kommandozeile ab, wie im Linux, will man kompliziertere und dabei stets zuverlässigste Netzwerkgeschichten fahren und OnTop auch noch jederzeit akkurate und aktuellste Informationen über und jeden im LAN einsehen können

(Naja, wenigstens hats im Windows ja die Managementconsolen, die machen einiges ein bisschen hübscher, wenn man denn die Dinger auch finden kann )