MilesTEG1

Non j’ai un autre utilisateur dédiés à Plex 😉 Vu que c’est l’image docker c’est ok. Ça aurait été le paquet dsm là par contre je n’aurais pas eu le choix 😊

@KSCMC'est étonnant ta version. Tu n'aurais pas utilisé un .deb fourni par ChuckPa du forum Plex ? Car je suis comme @_DR64_ : (bon moi j'utilise l'image officielle : plexinc/pms-docker:plexpass @KSCMPetite question : pourquoi tu passes par un script pas pratique à modifier pour créer ton conteneur ? Pourquoi n'utilises-tu pas un fichier docker-compose ? C'est quand même plus simple à maintenir... Et si tu es sous DSM 7.2, tu peux directement l'utiliser avec Container Manager. Sinon tu fais : pour créer le conteneur la première fois : docker-compose up -d pour mettre à jour : docker-compose down && docker-compose pull && docker-compose up -d Ou bien tu utilises Portainer.

@Jeff777ho bah c’est rare que je ne vois pas passer ce genre de sujet… pour les 500Go je vais te les laisser 😊 il auraient un 0 de plus le te les prendrais bien 😊 mais là … 😁

Oh je n’ai pas vu passer le sujet 😅 Mise à jour sans soucis sur mon 920+. et ça m’a fait un vrai reboot. Par contre la maj du paquet Container Manager a due être suivie d’un reboot.

Si tu ne sais pas quoi faire de ton 8To je veux bien te le racheter 😁 sinon personne n’a parlé ici de la version update 1 de dsm 7.2 qui est sortie il y a quelques jours ? https://www.cachem.fr/synology-dsm-7-2-update-1-la-premiere-mise-a-jour-officielle/

Sur mon 920+, j'ai la même chose niveau kernel : Linux Syno-DS920Plus 4.4.302+ #64570 SMP Sat Jun 3 00:00:25 CST 2023 x86_64 GNU/Linux synology_geminilake_920+

@Jeff777Mon hypothèse est qu'ils n'ont pas fait de package de mise à jour pour passer de -64561 à -64570, et que donc cette version -64570 remplace purement et simplement la précédente. Ceux qui n'ont pas installé cette -64561 ne devront pas passer par son installation préalable à la -64570.

@tous Petit retour sur mon souci de transo HW qui s'affiche en tant que telle, mais ne fonctionne pas. Je devrais dire ne fonctionnait plus, car avec les manipulations suivantes, j'ai refait fonctionner le serveur. Mais déjà, il faut que je dise que j'avais copier tel-quel le dossier .../docker/plex/config/ depuis le synology sur lequel j'avais mis le PMS le temps que l'asustor revienne de SAV. Et il s'avère que certains dossiers ne devraient pas être copié comme ça... (voir ici) Du coup j'ai supprimé les dossiers et fichiers suivants : # Fichiers : /Preferences.xml /.LocalAdminToken /plexmediaserver.pid # Dossiers : /Drivers /Codecs # J'en ai profité pour supprimer ceux-là aussi, car trainant du contenu depuis je ne sais combien de versions : /Crash Reports /Diagnostics /Logs J'ai recréé le conteneur de 0 donc et voilà, après une phase de reconfiguration (due à la suppression du fichier Preferences.xml , et un redémarrage, PMS refonctionne correctement, la transco HW est bien fonctionnelle, et la lecture du média est fluide et rapide. Bref, tout ça pour dire, que si parmi vous, certains qui ont le souci de transco HW non fonctionnelle, ont migré leur PMS de machine en machine, vous pourriez tester ma manip, elle sera peut-être fonctionnelle pour vous. PS : Initialement le PMS était sur le Syno DS920+, puis quand j'ai eu l'asustor, je l'ai migré sur ce dernier en copiant via rsync le dossier de configuration. Ayant eu des soucis de transco sur l'asustor, j'ai remigré sur le Syno. Puis rebelote quand les soucis de transco ont été résolus sur l'asustor, PMS de retour sur l'AS. Puis (encore), migration sur le Syno quand l'AS est parti en SAV. Et retour encore sur l'AS depuis quelques jours. Pfiou, il en aura fait des voyages XD Du coup, je vais me faire un petit script qui va faire une copie rsync de l'AS vers le Syno sans les dossiers mentionnés précédemment. Avec arrêt du PMS avant, puis redémarrage ensuite.

Le seul conteneur que j'ai installé via la nouvelle interface de DOcker sue DSM 7.2, donc Container Manager, c'est Portainer et Portainer Agent 😄

Hello, bon et bien en rebasculant mon PMS sur l'Asustor qui est revenu de SAV, même si j'ai la transco HW qui s'affiche, le CPU monte en flèche, et la transco ne se fait pas vraiment : vidéo bloquée... Et ce, avec ou sans le Activer le mappage tonal HDR Sur l'Asustor, pour que la Transco HW fonctionne il faut activer cette option : Par acquis de conscience, j'ai décoché, reboot, puis recocher puis encore reboot. Mais la Transco n'est toujours pas fonctionnelle... J'ai revérifier les permissions de /dev/dri/ et c'est bien en 666. Pour une vidéo lue en directe mais avec HDR sur un périphérique non HDR, ça transcode bien pour le tonemapping, mais pas de baisse de qualité. Lecture fluide. Mais dès que je veux baisser la définition et le débit (vidéo de base @25,1 Mbps) à 1080p@20Mbps : Et la lecture n'est plus possible...

Je modifierai le script pour vérifier si le /tmp est bien autorisé en lecture/écriture. du coup , je pars sur le principe que les dossiers ne sont pas créés ? Ou que seul le dossier du conteneur l’est ? C’est ma préférence là, ce dossier doit être créé et on y place le script qui va créer les autres dossiers , potentiellement leur attribuer les bons droits (vi ID utilisateur avec un chown) puis placer les différents scripts qui se lanceront dans le conteneur. tu ne voudrais pas créer un dépôt GitHub pour stocker ces fichiers ? Le script les téléchargera de là (c’est ton tuto après tout, je ferai des PR pour le script). La ligne de commande reste nécessaire pour faire ce que tu veux faire , moi j’apporte juste une unification des commandes au sein d’un script car je n’aime pas taper les commandes les unes à la suite des autres 😜

PS : tu as vu que pour récupérer la dernière version, pas besoin d'indiquer la valeur de la version, le script la récupère tout seul.

@loli71 De rien, pas de souci, je le mettrais à jour. Je vais faire un dépôt github ou un gist pour que ce soit plus simple ^^ Pourtant, dans tes commandes, c'est pas /tmp que tu utilises : Oui c'est sûr, mais pour être tranquille, j'aime bien que ça vérifie les dossiers. S'ils sont déjà existants, la commande ne fera rien 🙂 Très bonne idée 🙂 Je finalise le script dès que je peux, et le reposte. Tu verras si tu l'intègres au tuto et donc fait quelques modifs pour aller avec le script 🙂 (je n'oblige à rien 😉 )

Alors, avant d'aller faire dodo, superbe tuto qu'il me faudra mettre en place prochainement 😉 Deux petites choses que je ferais un peu autrement : Ce qui suit mérite d'être mis dans un fichier script, pour ne pas avoir de problème d'échappement de variable Je proposerai ceci : #!/bin/bash # Script pour télécharger la version choisie de wireguard-ui VERSION="0.5.1" # Changer la version pour pointer sur la dernière (voir un peu plus bas) ARCHI="amd64" # Changer architecture si besoin docker_volume="volume1" # Changer pour le volume dans lequel se trouve le dossier docker # Par exemple : volume4 nom_conteneur="wireguard" # Changer par le nom du conteneur qui sera créé. # Servira comme nom de dossier dans le dossier docker temp_dir="tmp/" ########################################################################################## # Si la volonté est d'avoir la dernière version disponible, ceci peut aider. # Commenter les 3 lignes suivantes si latest_gh_version="${$(curl -sL https://api.github.com/repos/ngoduykhanh/wireguard-ui/releases/latest | jq -r ".tag_name"):1}" printf "La dernière version disponible sur GitHub est la : %s\n" $latest_gh_version VERSION=latest_gh_version ########################################################################################## return_code="" dossier_conteneur="/${docker_volume}/docker/${nom_conteneur}" if [ ! -d "${dossier_conteneur}" ]; then echo "Le dossier ${dossier_conteneur} n'existe pas. On va le créer." mkdir -p "${dossier_conteneur}" return_code="$?" if [ "$return_code" -ne 0 ]; then echo "Erreur à la création du dossier temporaire $temp_dir... Fin du script." exit 1 fi fi return_code="" if [ ! -d "$temp_dir" ]; then echo "Le dossier $temp_dir n'existe pas. On va le créer." mkdir -p "$temp_dir" return_code="$?" if [ "$return_code" -ne 0 ]; then echo "Erreur à la création du dossier temporaire $temp_dir... Fin du script." exit 1 fi fi cd "$temp_dir/" wget -O "wireguard-ui-${VERSION}-${ARCHI}.tar.gz" "https://github.com/ngoduykhanh/wireguard-ui/releases/download/${VERSION}/wireguard-ui-${VERSION}-${ARCHI}.tar.gz" || exit 1 tar -zxf "wireguard-ui-${VERSION}-${ARCHI}.tar.gz" mv wireguard-ui "${dossier_conteneur}/wireguard-ui/wg-ui" rm -f "wireguard-ui-${VERSION}-${ARCHI}.tar.gz" # Fin du script. (Bon OK, je me suis un peu lâché ^^) Demain, enfin dans la journée, je ferais une autre version du script avec option --update pour faire la dernière partie avec ceci : cat <<EOF | docker exec --interactive wireguard bash s6-rc stop custom-svc-wg-ui.sh cp -f /wireguard-ui/wg-ui /app/wg-ui s6-rc start custom-svc-wg-ui.sh EOF

La comme ça je dirais de mettre des " " entourant l’URL. je regarderai demain.

Oué c’est étrange… ton nom de domaine pour le vpn ne passe pas par un reverse proxy ?

@PiwiLAbrutiJ'ai fait la MAJ hier vers la 7.2-64570. Pas de souci rencontré pour lancer et faire la MAJ.

Pour moi c'était évident que ça ne serait pas ce driver le problème. Alors ça... Faudrait demander au support Synology...

Mais du coup, c'est une utilisation à 80% de cette partition qui cause l'échec de la MAJ ?

As tu essayer plus tard de te reconnecter ? Ça m’arrive de temps à autre quand je coupe la connexion de n’a pas réussir à le reconnecter dans la foulée. Mais quelques minutes après oui. essaye aussi en n’étant pas connecté au wifi de la box mais bien en passant par la 4G du téléphone.

Sur mon DS920+ qui a fait la MAJ ce matin, sans soucis autres que le volume sur SSD NVMe : ~$ sudo fdisk -l /dev/md0 Password: Disk /dev/md0: 2.4 GiB, 2549940224 bytes, 4980352 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes ~$ df -h /dev/md0 Filesystem Size Used Avail Use% Mounted on /dev/md0 2.3G 1.5G 681M 70% /

Bon pour information, après un vrai reboot, mon volume NVMe est réapparu correctement dans DMS. Merci au script https://github.com/007revad/Synology_HDD_db qui ajoute les disques dans la base de compatibilité du NAS, que j'ai paramétré (planificateur de tâches) pour se lancer à chaque reboot du NAS. Je n'ai rien eu d'autre à faire que de redémarrer le NAS.

@StéphanH Ce n'est pas tout à fait le même paquet, mais la configuration est sensiblement la même : Et dans le journal de connexion je ne vois que des IPv4 pour les périphériques connectés.

La différence entre ces deux versions de DSM 7.2 : https://www.diffchecker.com/P4QUe7Lb/ Sinon, ça m'a encore mis en carafe le volume de SSD NVMe que j'ai depuis DSM 7.1. Et la maj ne fait pas un vrai reboot du NAS. Je le redémarre proprement pour voir si mon volume NVMe revient ou si je vais devoir le refaire à la main comme après la première MAJ en DSM 7.2

C'est étonnant... Tu as bien suivi ce tuto ? Notamment sur les ports à ouvrir et à ne pas ouvrir sur le routeur, et ceux obligatoires sur le NAS. car je peux confirmer que le L2TP fonctionne parfaitement depuis mon iPhone 7 (sous iOS 15.7.6) avec sosh (donc adresse ipv6). Ça fonctionne aussi très bien depuis macOS (via le partage de connexion de mon iphone). J'utilise le ndd synology , et le serveur VPN est sur le routeur Synology. Mais quand il était sur le NAS, pas de soucis non plus.