Reply to thread

Message: <blockquote data-quote="resa" data-source="post: 1165324" data-attributes="member: 68500">[USER=74879]@HTPCSourcer[/USER] : 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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink    ;)" loading="lazy" data-shortname=";)" />[USER=109209]@radical[/USER] :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 [USER=74879]@HTPCSourcer[/USER] 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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin    :D" loading="lazy" data-shortname=":D" />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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink    ;)" loading="lazy" data-shortname=";)" /> 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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin    :D" loading="lazy" data-shortname=":D" />(Kleiner Scherz <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink    ;)" loading="lazy" data-shortname=";)" /> )  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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink    ;)" loading="lazy" data-shortname=";)" /> 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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink    ;)" loading="lazy" data-shortname=";)" />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<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin    :D" loading="lazy" data-shortname=":D" />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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin    :D" loading="lazy" data-shortname=":D" />(Naja, wenigstens hats im Windows ja die Managementconsolen, die machen einiges ein bisschen hübscher, wenn man denn die Dinger auch finden kann <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin    :D" loading="lazy" data-shortname=":D" />)</blockquote>

Verification