Beiträge von eol92

    DESKTOP.ini

    Das heißt dann wohl, dass die Rechner via Windows auf das NAS zugreifen!? Gibts auch Linux-Rechner im System? Dann könntest Du die Dateien finden find und gleichzeitig löschen. Leider erinnere ich mich nicht daran ob Desktop.ini vom Windows-System benötigt wird - und falls ja, wofür. Soviel ist aber sicher: Gelöscht bleiben Sie nicht, Windows wird sie immer wieder neu anlegen.

    Am PC ist der Qnap Folder Ordner auch leer.

    Ist (scheint) er leer (zu sein), weil Du über eine SMB oder NFS Freigabe draufgeschaut hast? Oder hast Du via Files am Browser kontrolliert, ob die Dateien weg sind?


    Daten löschen sich ja Gott sei Dank nicht mal eben so aus Jux und Dollerei selbst. Wenns gut läuft, hat Dir vielleicht nur ein Qnap Update in die Suppe gespuckt, wenns hart kommt, hat/haben sich womöglich HDDs verabschiedet.

    Bei PC -> NAS laufen die Daten nur eine Strecke, was die höhere Datenrate erklären könnte.


    Filesystem auf den NAS ist EXT4/RAID5. Filesystem auf dem PC ist NTFS.

    Das, was ich über NTFS beschrieben habe, bezog sich ja auf das Schreiben auf eine NTFS HDD. Ehrlich gesagt habe ich mich nicht weiter darum gekümmert, denn nachdem ich NTFS zu ext4 geändert hatte, lief alles wie gewünscht. Ich habe das damals nicht einmal in dem Forum (arch) zugegeben, da man sich um mein Anliegen gekümmert hatte, ich aber im Leben nicht auf die Idee gekommen wäre das Windowsdateisystem in die Diskussion einzubringen. Einfach geschämt.


    So wenig, wie ich mir vorstellen konnte, dass die Schreibgeschwindigkeit durch NTFS so derart in den Keller ging, so wenig kann ich mir vorstellen, dass die Lesegeschwindigkeit derart darunter leidet. Ca. 40 MB pro Sekunde, wie bei Dir, sind ja nichts. Jeder bessere USB-Stick schafft da mehr.


    Schön wird das bei Dir nicht. Jeden Switch, jedes Kabel checken... da würde ich mal bis November warten wenn es draußen ungemütlich, nasskalt ist. Schöne Wochenendaufgabe. Man gönnt sich ja sonst nichts.

    Meine o.a. Werte erreiche ich aber auch bei NAS/NAS Kopplung per RTRR.

    Echt? Grade mal mein kleines Skript laufen lassen: (Zwischen NAS und Laptop hängen zwei 1 GB Switche.)


    3 Daten vom NAS auf den Laptop: 7628681811 Bytes in 66 Sekunden ergibt rund 110,23 MB/sec. (WLAN: 35,5 MB/sec)

    Zurück aufs NAS in exakt 70 Sekunden ergibt 103,93 MB/sec. (WLAN: 19.25 MB/sec)


    Die Ausgangsgröße 7628681811 zwei mal mit dem Wert 1024 geteilt.


    Und Alv meinte ja:

    Kopieren von der SSD des PC auf ein NAS kann kurzfristig ca. 40MByte/s erreichen.

    Dass NTFS auf dem NAS ausgeschlossen ist, hatte ich ja erwähnt.


    Was mich persönlich angeht, so muss ich leider zugeben, dass mich die QNAP-Apps nicht gerade vom Hocker hauen. Vielleicht lädt er ja via File Station eine Datei von der PC-SSD aufs NAS? Braucht bei mir auch länger.


    NAS-Ordner mounten (keine Ahnung wie man das in Windows macht) und mal so Dateien kopieren.

    bestenfalls auf 25MByte/s, fällt aber oft auf ca. 8MByte/s ab.


    Was mache ich falsch?

    Da Du vor 37 Minuten (und nicht vor 6 Jahren gepostet hast :evil: ) bin ich mal so frech:


    Man kann meine Erfahrung nicht auf Dein Erlebnis übertragen, da Du von Kopiervorgängen NAS --> NAS berichtest. Deine beschriebenen Werte decken sich aber total mit meinen Erfahrungen. GB LAN, aber Übertragungen lediglich in den Spitzen bei max. 30 MB/sec. Daran bin ich schier verzweifel. Von Samba auf NFS gewechselt (bis heute dabei geblieben) - Ergebnis: NIX! Neue Kabel: NIX. Rechner getauscht.... In der Wohnung sah es nach zwei Tagen aus wie nach nem Bombenangriff. Denn eigentlich sollte ich im Idealfall doch bis zu 112 MB/ sec.haben.


    Es war noch zu einer Zeit (lange ist's her), als ich für alle Fälle kompatibel zu Windows bleiben wollte. Warum auch immer. Und so war die Zielplatte NTFS. Testplatte angehängt, mit ext4 formatiert und siehe da: Tatsächlich in echt über 100 MB/sec.


    Ich habe noch immer ein Miniscript, das mir ca. 12 GB vom Quellrechner holt und danach wieder zurückschickt. In eine kleine Logdatei lasse ich mir Uhrzeit Start/Ende des Kopiervorgangs reinschreiben, um dann aufs Byte und die Sekunde genau die Geschwindigkit auszurechnen.Heute bin ich schon enttäuscht, wenn es mal nur 90 MB/sec. sind.


    Wie gesagt: NAS --> NAS schließt natürlich NTFS aus. Leider

    Hallo Sebastian,


    ich nutze ausschließlich NFS. Dass diese Verbindungen nach einer Zeit getrennt werden, habe ich (seit Jahren) noch nie erlebt. Der erste Gedanke, der mir kam - und für den ich sicher abgewatscht werde - war der: Debian 12 ist untätig und wechselt nach Zeit X in Suspend. Das würde erklären, warum nach einem Neustart eine gewisse Zeit alles wieder funktioniert.


    Klingt banal und basiert mit Sicherheit auf meinen Deppenkenntnissen, aber völlig ausschließen würde ich es nicht.

    Meine Frage ist nur, ob das einigermaßen ausreichend für streamen vom NAS
    auf den TV ist.

    Grundsätzlich würde ich behaupten wollen, dass WLAN ausreicht. Zwar hängt bei mir sowohl TV, als auch NAS am LAN, aber da mir der TV einfach zu lahmarschig ist (was die Apps angeht), hängt dort am HDMI ein TV-FireStick, der "nur" über WLAN im Netz hängt und ausschließlich zum Streamen der Videos vom NAS zuständig ist.


    WLAN bedingte Aussetzer konnte ich noch nie beobachten. Allerdings habe ich auch noch keine 4K Videos gestreamt. bei Full HD war seither Schluss. Müsste sich aber ausrechnen lassen: Gesamtgröße (MB) des 4K Videos geteilt durch Länge des 4K Videos in Sekunden. Sollte nun ein Wert über Deinen 25 MB/sec. heraus kommen, wäre WLAN unbrauchbar.


    Ok, ich revidiere meinen Post. Weil es mich auch selbst interessiert hat, habe ich testweise ein 74 sekündiges, legales 4K Test-Video mit 576,38 MB heruntergeladen, auf das NAS kopiert und getestet. Der FireStick über WLAN macht schlapp (Quelle zu langsam) die LAN Verbindung TV--> NAS läuft problemlos.


    Und das, obwohl 576,38 MB / 74 Sekunden nur 7,78 MB/sec. sind. :ziped: Bei FullHD sind es allerdings weniger als 3,5 MB/sec.


    Gott sei Dank werden noch nicht so viele 4K Videos gesendet, die man aufzeichnen, auf dem NAS ablegen und dann von dort streamen könnte. Sonst müsste ich meine WLAN-FireStick in die Tonne treten.

    Was immer Ihr jetzt denken werdet: Mein NAS ist völlig leise, Lüfter dreht mit ca. 1.100 RPM. Und das ist so, seit ich eine externe Seagate Expansion 4TB vom USB 3 abgezogen habe. Eine Kausalität kann ich zwar nicht nachvollziehen, aber es ist, wie es ist!

    Ah.. ok, jetzt wird es schon etwas deutlicher.


    Ich habe seither so um die 12 TB mit einem 11 Jahre alten i7 Laptop erledigt. Ein Raspi 3, der 24/7 wegen Pihole online ist, hat ihn täglich aufgeweckt und somit das Backup angestoßen. lvm2 auf dem Debianbasierten System war ja schnell installiert.


    Suboptimal daran war, dass dieser alte i7 ausschließlich über USB 2 und ausschließlich über Fast Ethernet verfügte.


    Also bin ich umgestiegen auf einen Pi 4 mit 8 GB, 1Gbit und 2 x USB 3: Viel schneller.


    Achtung, jetzt kommt der Aufreger mit dem ich mich disqualifiziere: Ich arbeite tatsächliche gerne :X mit systemd timer units.


    Der Raspi 4 startet automatisch durch eine 9,90 Euro Tapo Steckdose, arbeitet den systemd-timer ab, der den Raspi das eigentliche rsync - Script starten lässt.


    Die rsync Logdatei schreibt er in ein Verzeichnis auf dem NAS, sodass ich täglich kontrollieren kann ob und was er gesichert hat. Danach hängt er sowohl die eigenen LVM, als auch die NAS-Ordner, die er natürlich gemounted hat, aus. Und dann kommt der shutdown -h 0.


    Die 9,90 Euro Tapo schaltet den Strom der 3 HDDs des LVM und den Raspi 4 zeitverzögert nach 1 Stunde wieder ab. Am nächsten Tag gehts wieder von vorne los. Selbst wenn die Stunde mal zu knapp wäre, würde er das unvollendete Backup vom Vortag vervollständigen. Am Anfang waren es 2 Stunden. Heute braucht er aber maximal 10 Minuten.


    Wirklich wichtige Daten wie Dokumente bspw, sichere ich doppelt und dreifach.


    Läuft seit Jahren (inklusive Restore!) absolut zuverlässig, schnell (1 Gbit/ USB 3) und für mich wichtig: Nicht die Quelle startet das Backup und schiebt Dateien auf den Backup-Server, sondern der Backup-Raspi übernimmt die Kontrolle des Backups, holt sich die Dateien.


    [Edit] Dem Backup Raspi habe ich komplett den Ínternetzugang gesperrt, wird regelmäßig für ein update kurz aufgehoben. Ich will auch , dass die Backup-LVM nicht nur via umount vom System getrennt werden, sondern komplett, wie der ganze Raspi vom Strom/LAN getrennt sind. Andere würden mit Sicherheit auch noch die Platten verschlüsseln. Warum auch nicht!? Ich mach es halt nicht. [/EDIT]

    Sorry, wahrscheinlich habe ich keinen Durchblick. Quelle und Ziel befinden sich im selben Netz oder ist die Quelle und/oder das Ziel außer Haus?


    Ignorier' mich einfach, wenn meine Zwischenfrage die intellektuelle Qualität der seitherigen Diskussion rund um die Problemlösung stört.


    Mir hat sich nämlich seither einiges noch nicht so ganz erschlossen:


    1. Warum openmediavault?
    2. Warum WebDAV?
    3. Warum HBS?
    4. Warum nicht rsync?

    Mein Panasonic-TV ist allerdings schon älter. Da werde ich mit Fremdsoftware nicht klar kommen. Hätte ich da vielleicht mit einem Fire-TV-Stick eine Chance?

    Fire-TV-Stick an HDMI des TV anschließen, auf dem Stick Kodi installieren, über SMB oder NFS auf die entsprechenden Ordner des NAS zugreifen. Vorteile unter anderem: Sehr schnell, absolut zuverlässig, keine Neuindizierung der Mediadateien auf dem NAS erforderlich...


    Auf dem Stick solltest Du aber ab einer bestimmten Menge an bspw. Videos (mehrere tausend) vermeiden, dass KODI sich die Daten zu den Videos aus Datenbanken holt, dazu reicht dann irgendwann sein Speicher nicht mehr.


    Selbst wenn Dein Sony TV aus 2016 mit DLNA umgehen könnte, wirst Du niemals so flüssig und schnell arbeiten können, wie dem Fire-Stick.


    Anmerkung: Aus eigener Erfahrung!

    Vorausgesetzt Du setzt moderne Smart-TVs ein, ließe sich an diesen mit an Sicherheit grenzender Wahrscheinlichkeit KODI installieren, als APP nicht unbedingt einfach zum Download bereit, über den Browser (im TV) jedoch schon.


    Zugriff auf Deine Medien via SMB/NFS.


    Wesentlich komfortabler ist ein TV-Firestick deshalb, weil der mit installiertem KODI sehr viel schneller läuft, als KODI direkt auf dem TV. Freie HDMI am TV natürlich Voraussetzung.

    Mein Backup Script, das auf rsync basiert und von einem Linux-Backupserver täglich angestoßen wird, löscht vorher alle @__thumb Dateien/Ordner auf dem Qnap.


    Diese @__thumb aber gar nicht erst aufkommen zu lassen, wäre mir trotzdem lieber. :/


    Die Sache mit dem "Indexen" kenne ich irgendwie noch von minidlna. Da konnte man den Vorgang aber eben mit einem cronjob bzw. systemd timer unit automatisch anstoßen. Deswegen die Frage, ob sowas schon mal jemand auf dem Qnap realisiert hat!


    Auf einem Gerät komme ich mit Kodi bzw. TV-FireStick einfach nicht weiter. Nur für dort würde ich gerne mit dem Qnap DLNA arbeiten.

    Hallo,


    üblicherweise nutze ich Kodi (meistens in Verbindung mit TV-FireStick) schon wegen der Geschwindigkeit - also alles gut!


    Für einen speziellen Fall würde ich aber gerne die Multimedia Console als DLNA Server verwenden. Zwei Dinge stören mich dabei aber doch ziemlich:


    1.) Ich muss (?) die Indizierung der Inhalte jedes Mal händisch anstoßen! Kann man das mittels bspw. Cronjob automatisieren?

    2.) Obwohl ich die Miniaturansichtsgenerierung deaktiviert habe, werden mir bei jeder neuen Indizierung hunderte versteckte @__thumb Ordner angelegt.


    Die versteckten @__thumb Ordner lasse ich zwar automatisch vor dem Backup entfernen, lieber wäre es mir aber sie würden gar nicht erst auf meinen Hdds landen.


    Hat irgendjemand eine Lösung? Danke vorab.

    Dann liege ich bei aktuell 48°C (HDD1) und 50° C (HDD2) auch nicht soooo weit weg. Blöd natürlich, dass ich damals beim Kauf nicht auf die Idee kam mich auch noch um die Frage Helium oder Luft zu kümmern.


    OK, ich sage mal Danke so weit.