Freebox Server (Pop V8/ Delta V7 / Revolution V6 / Server Mini 4K)

  • Status Nouveau
  • Percent Complete
    0%
  • Task Type Anomalie
  • Category Services locaux → SMB
  • Assigned To No-one
  • Operating System Freebox Server V8 (Pop)
  • Severity Medium
  • Priority Very Low
  • Reported Version 4.3.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 3
  • Private
Attached to Project: Freebox Server (Pop V8/ Delta V7 / Revolution V6 / Server Mini 4K)
Opened by Tehoden - 24/04/2021
Last edited by aastier - 26/04/2021

FS#34655 - Bug propriétés à 0 + bug d'accès VLC en SmbV2 (FreeboxOS 4.3.0)

Bonjour,
Je faisais partie des beta testeurs et j’ai échangé plusieurs mails avec Mr Makassikis à ce sujet. je vais essayer d’être le plus clair possible. J’ai un disque de 5 To, en NTFS, connecté sur le serveur pop (sur l’Usb3 et le disque est USB3 aussi). Le disque est neuf, acheté en Janvier dernier, un peu avant le début de la béta. J’ai constaté que, sur certains répertoires (ceux avec beaucoup de fichier), si je fais un clic droit sur un fichier, la fenêtre des propriétés affiche un poids de 0Ko et aucune date de création/modification:

nsm09.casimages.comimg2021042421042408501917398417385462.jpg

Dans ce même répertoire, certains affichent correctement la fenêtre des propriétés et certains, comme l’image ci-dessus, sans rien.
Si on tente de parcourir le répertoire en question, par la commande dir en fenêtre CMD, le comportement est également très bizarre. une fois dans le répertoire, si je fais simplement dir, tous les fichiers du répertoire sont trouvés mais pas par ordre alphabétique. Ils sont bizarrement classés. Ils ont l’air (c’est à dire la majorité d’entre eux) d’être par ordre alphabétique mais pas du tout. Tous ceux qui sont pas bien “classés” sont ceux qui présente le bug de la fenêtre de propriétés. j’ai tenté toutes les options de la commande dir mais ça reste pas dans le bon ordre.
De plus, si, sur un fichier présentant le bug de la fenêtre des propriétés, je tente de faire un dir débutdunomdufichier*.*, là, la commande dir me répond que le fichier est inexistant. Résultat étonnant car un dir simple l’a pourtant bien “trouvé”, il est listé. Alors certes, pas au bon endroit dans l’ordre alphabétique mais il est là.

Bug lié à tout ça : Si dans VLC par exemple (depuis téléphone Android ou le lecteur freebox pop), je tente l’accès sur le répertoire avec ce bug, VLC me répond que, tenez vous bien, le répertoire est vide! alors qu’il contient plus de 200 fichiers.

Je vérifie le disque, histoire qu’il ne soit pas défectueux. Je branche le disque sur mon pc puis je le partage sur mon réseau (mon pc a bien smb V1 de désactivé bien sûr et tous les VLC utilisés ont l’option “préférer smbv1” de décochée également). Et la, tout fonctionne parfaitement, tous les répertoires sont biens listés par VLC, du téléphone, de la freebox tout … impec. Le bug de la fenêtre des propriétés à 0 disparait. Les commandes dir fonctionnent parfaitement. Le disque n’est donc pas en cause.

Une fois le disque rebranché sur la freebox, le bug est de retour. Je constate que n’importe quel répertoire dépassant les 30 fichiers présente ces bugs (mais ce n’est peut être pas pile ce nombre à partir duquel le bug se présente mais j’ai pas mieux, j’ai soit des répertoires à moins de 30 fichiers et la aucun souci ou j’ai beaucoup plus de 30, genre 80-100 voir plus de 200 fichiers, où la le bug est présent) :

- Des fichiers avec fenêtre de propriétés à 0
- exploitation par dir en fenêtre de commande CMD bugée
- VLC ne trouve rien dans ces répertoires, il les voit vide

J’ai refais plusieurs mails à Mr Makassikis mais sans réponses cette fois. J’ai pu voir qu’on était plusieurs à rencontrer des bugs assez similaires (avec d’autre logiciels que VLC). Je pense qu’il reste un bug, lié au nombre de fichiers contenus (ou bien tout autre chose mais il reste un bug, assez gênant car perturbe l’utilisation de VLC).

En espérant avoir une réponse cette fois, sinon je ferais un ticket peut être indépendant histoire de remonter le souci.

Merci beaucoup @ bientôt. Tehoden.

Bonjour bonjour :), un petit mot pour dire que depuis la dernière mise à jour, le bug est toujours présent et surtout, avec la dernière version, la connexion VLC sur le disque dur partager du serveur pop n'est plus du tout possible (en smb v2). Que se soit VLC sur mon portable, depuis le player pop ou la version UWP Microsoft, au moment de la saisie du user/mot de passe, l'authentification est refusée, la fenêtre de saisie du user/mot de passe réapparaît et impossible de se connecter et parcourir le disque.

@Tehoden : Avez-vous toujours le bug de "propriétés à 0" ainsi que vos autres bugs avec Freebox OS 4.4.0 ?
En gros, quels sont les bugs à ce jour ?

Avez-vous aussi le bug "fenêtre bloquée à 99%" ?
Si oui il faudrait l'indiquer ici : https://dev.freebox.fr/bugs/task/34842.

Afin que @mmakassikis puisse faire le nécessaire.

Merci d'avance.

Bonjour ..
merci pour votre message et la prise en compte de ce souci :). j'ai effectué la mise à jour 4.4.0 hier soir. J'ai connu un reboot sauvage ce matin, sans raison. Pour le souci de la fenêtre des propriétés à 0, elle est malheureusement toujours d'actualité.

Concernant le blocage à 99%, personnellement, et ce depuis le tout début de la beta smbV2, je n'ai jamais connu ce blocage. J'ai un doute (et j'ai du mal à reproduire et à le diagnostiquer correctement) sur un bug qui concerne la copie d'un répertoire complet. Une fois copié, quelques temps après la copie, la box devient instable. Est-ce réellement lié à la copie, je n'en suis pas sûr.

Pour résumé, bug en cours : la fenêtre de propriété à 0
Bug suspecté : instabilité sur une copie de répertoire.

Les connexions VLC sont fonctionnelles.

Voilà merci.
Cordialement, Tehoden.

@Tehoden : Je suis un client comme vous, mais il faudrait que @mmakassikis puisse voir ce ticket… Pourriez-vous quand même lui dire dans le ticket qu'il suit déjà : https://dev.freebox.fr/bugs/task/34842 avec le lien vers celui-ci ?
Il n'est pas du tout apparu dans ce celui-ci…

En 4.5.0, le problème est toujours là ?

Bonjour,
je viens pour préciser qu'effectivement, j'ai testé hier et le souci est toujours présent. Je parle uniquement du souci concernant la fenêtre des propriétés à 0. J'ai mis un peu de temps à répondre car mon pc principal n'est plus sous Windows, uniquement mon pc portable, qui lui est bien à jour en 21h2. Le bug est toujours présent donc sur ce dernier. C'est avec ce pc portable que j'avais réalisé les captures Wireshark que j'ai envoyé à Mr Makassikis.

Pour mon pc principal, ce dernier est maintenant sous Linux Mint et j'avoue ne pas constater le moindre souci … il y a de forte chance que cela soit lié à Windows (un bug sous jacent côté Windows qui provoquerai cela).

merci beaucoup.

@Tehoden : Quelle est la situation avec le Server en 4.7.0 ?

Tout bug doit être spécifié pour que @mmakassikis puisse jeter un œil… Il a déjà fait beaucoup depuis le développement du code.

Hello @Neustradamus_,

Alors en 4.7.0, je ne rencontre plus aucun souci avec VLC (depuis plusieurs versions d'ailleurs).

Par contre, le souci de la fenêtre des propriétés Windows buggé est malheureusement toujours présent (Windows 11 maintenant).
Je n'ai pas refait de tests bien précis et détaillés mais toujours des poids de fichiers à 0.

Il se trouve que par contre, et ça depuis les versions 4.6, un comportement moins bon sur la vitesse de transfert. Tous les débuts de transferts sont très lents (quelques ko/s). Cela peut durer bien 30-50 secondes puis petit à petit le débit remonte et arrive, difficilement à 27, 28 Mo/s sur un fichier de 6-7 Go.
Il est même arrivé que le débit étant si lent que Kodi à pensé que les vidéos du disque n'étaient plus là et les a supprimé de ma vidéothèque :/

Dans l'ensemble je ne peux pas dire que ça ne fonctionne pas. Les transferts se font bien (de mon pc portable Windows ou mon pc fixe linux Mint 20), lentement au début mais bon ils se font. Les lectures depuis VLC, Kodi ou autre ne posent pas de problème.
Merci à tous et merci à @mmakassikis!

Admin

@Tehoden

Si je comprends bien la situation avec Kodi, il n'y a pas de problème de lecture mais il y en a parfois à l'indexation ?

Pouvez-vous m'indiquer sur quel OS est-ce que Kodi est installé, et comment il accède au partage SMB ?

De mémoire, il est possible qu'il se connecte directement à la cible (donc en utilisant un client à lui) ou bien de spécifier un répertoire (par exemple, monté avec mount.cifs sous Linux ou un lecteur réseau sous Windows).

Par rapport aux vitesses de transfert: est-ce que cela se produit indépendamment des clients ?
Il y a effectivement eu des changements à ce niveau là pour éviter qu'un client monopolise les ressources de la box, par contre dans mes tests l'impact sur les performances était à peine visibles.

Comment sont connectés les clients (WiFi / Ethernet) ?

Bonjour Mario, merci pour la réponse. J'ai fait 1-2 tests de plus suite à mon message pour essayer de ciblé un peu mieux le comportement.

Mon dernier test :
- Copie d'une vidéo d'environ 6.5Go.
- Utilisation en parallèle de Kodi sur Google TV, sur ma TV Sony XR55 X90J

La source dans Kodi est par Smb et j'accède directement à la freebox.

J'ai lancé la copie depuis mon pc fixe, en Ethernet, sous linux mint 20.1 (cinamon), également par Smb.
la petit écran de transfert (fenêtre de progression) est resté longtemps en mode "Préparation au transfert" sans le commencer.

Après une dizaine de seconde, ma fille à lancer une vidéo sur Kodi sur ma TV, qui est en wifi (et prêt de la box, donc sur la carte 5Ghz).

le transfert sur mon mint est resté donc lent pendant un bon moment et ma fille a connu des coupures sur Kodi avec un message de Kodi disant que la source était trop lente.

le transfert s'est finalement réalisé, en atteignant 30Mo/s environ. Ma fille a eu 2-3 fois le message sur Kodi puis une fois le transfert terminé, plus de souci côté Kodi.

Si on ne fait pas de transfert, que je tente immédiatement une mise à jour de la base de Kodi, ou un nettoyage de la base de données. là aussi des lenteurs, Kodi met du temps pour commencer à détecter de nouvelles vidéos ou parcourir la bibliothèque. En fait, les lenteurs sont constatées du moment où on réveille le disque en quelque sorte excepté pour une simple lecture depuis Kodi.

Un cas par exemple où on lance uniquement une lecture depuis Kodi depuis ma TV. Kodi va "réveiller" le disque et le début de la lecture charge un peu mais 4-5 secondes puis la lecture se lance et ne plante pas.
Pendant la lecture, si ensuite, je lance une copie, elle démarre quasi normalement et avec un bon débit et la lecture Kodi n'est pas impactée.

Si j'attaque mon disque tout de suite par une copie ou des opérations de maintenance par Kodi, là les lenteurs sont présentes.

Elles disparaissent ensuite et globalement c'est peu préjudiciable. C'est juste assez présent pour qu'on le remarque et que je me pose la question mais pas de blocage.

J'espère être assez compréhensible lol … Merci Mario, @ bientôt.
Nicolas.

Admin
En fait, les lenteurs sont constatées du moment où on réveille le disque

La sortie de veille prend du temps indépendamment du moyen d'accès (vous devriez avoir le même compotement en passant par FTP ou UPnP).

Dans les différents scénarios, il s'agit d'opérations en parallèle sur un même disque. Surtout sur un disque mécanique, la chute de perf est énorme.

En relisant le post initial, je vois que le disque est en NTFS. Cela n'aide pas dans la mesure où ce n'est pas un système de fichier natif à linux (le driver rajouté récemment n'est pas suffisament mature, donc on repose sur l'implémentation userland. Celle ci est plus coûteuse en CPU et apporte de moins bonne performances que l'ext4 par exemple).

Marios

@mmakassikis: Est-ce possible d'ajouter exfatprogs?
- https://github.com/exfatprogs/exfatprogs/releases

Je n'ai pas encore fait le ticket pour…

Merci par avance.

A noter que j'ai parlé de ntfs-3g à mettre à jour ici :
- https://dev.freebox.fr/bugs/task/25772

J'en profite aussi pour nfs-utils :
- https://dev.freebox.fr/bugs/task/37232

Egalement pour hfsprogs "diskdev_cmds" :
https://dev.freebox.fr/bugs/task/25763

Hello, un petit message pour faire le point suite à la mise à jour en 4.7.1(dont le Changelog indique bien des optimisations SMBv2) :
Et bien différence vraiment notable concernant les lenteurs en début de copie. Même depuis mon linux, la copie débute rapidement et attaque à 18-19Mo/s pour monter vers 30-32 Mo/s ce qui est tout à fait correct. Je n'ai testé que 2 fois et je n'ai pas connu de situation avec lecture + copie en simultané sur le disque comme dans mon exemple mais il semble tout de même qu'il ait une nette amélioration.

Bonjour,
Est-ce que le bug "propriété à 0" est toujours la en 4.7.1 ? (j'ai plus de PC windows 10/11 pour vérifier )

Bonjour @eric12.
Alors ce bug n'est plus que partiellement corrigé.
L'imprime écran de la fenêtre de propriété ci-joint.

<a href="https://www.casimages.com/i/22111607400917398418051877.jpg.html" title="Mon image" target="_blank"><img src="https://nsm09.casimages.com/img/2022/11/16//mini_22111607400917398418051877.jpg" border="0" alt="Mon image" /></a>

On voit que Taille reste à 0 mais "sur le disque" montre bien la taille du fichier.
Il est toujours absent les dates de créations / modifications etc.

@mmakassikis: Que pensez-vous de la capture de @Tehoden?

@eric12, @Tehoden: Est-ce résolu en 4.7.5 ?

@eric12, @Tehoden: Qu'en pensez-vous en 4.7.8 ?

Salut à tous,
mise à jour effectuée ce matin. Je n'ai pas fait de tests poussés, j'ai beaucoup de taf mais à 1er vu, pour VLC, je ne crois pas avoir rencontrés de problème, depuis longtemps maintenant(cependant, je l'utilise rarement, j'accède à mon contenu principalement avec Kodi) et pour la fenêtre de propriété, seule la taille sur disque s'affiche, la taille en octets reste à 0 et aucune info de date (créé le, modifié le, dernier accès).

Hormis cela, l'utilisation est bonne, plus de plantage en copie, les débits sont bons, je n'ai pas rencontré de pb ces derniers temps. A voir plus précisément cette 4.7.8 car je n'ai vraiment pas testé pour le moment de lecture Kodi, de transfert etc.

A savoir aussi que le souci des propriétés n'est pas identique sous linux (Mint 21.2). Sous linux, seule la date de création est inconnue. Tout le reste est ok (taille, date de modification, dernier accès ok).
Merci à tous

BENUE commented on 29.07.2023 05:08

idem pour moi avec mise à jour 4.7.8 server DELTA, la fenêtre de propriété la taille en octets reste à 0 mais ta taille sur disque s'affiche sur certains fichiers photos mais pas tous … Rien à comprendre. est ce une histoire d'autorisations ? Je suis en SMBV2/3

BENUE commented on 25.08.2023 04:16

Toujours le même problème… pas de nouvelles ?????

@Tehoden, @eric12, @BENUE : Le problème est que si personne ne dit que le problème est toujours là, il n'y aura pas de solutions.

Si quelqu'un peut déjà faire un ticket afin que ce problème puisse être corrigé :
- https://github.com/cifsd-team/ksmbd/issues

Je vous remercie d'avance.

Il faudrait que @mmakassikis (Marios Makassikis), le spécialiste d'Iliad/Free/Freebox (que je félicite pour son travail depuis son arrivée) et contributeur de ksmbd/ksmbd-tools puisse ajouter, après que le ticket soit publié, les logs pour les fournir au développeur principal.

À noter que c'est aussi en lien avec celui-ci : https://github.com/openwrt/packages/issues/12933.

@Tehoden, @eric12, @BENUE : Quelle est votre situation de nos jours ?

Peut-être faire un ticket ici et mettre en lien @mmakassikis afin que cela soit enfin corriger… - https://github.com/namjaejeon/ksmbd-tools/issues
- https://github.com/namjaejeon/ksmbd/issues
- https://github.com/cifsd-team/ksmbd-tools/issues
- https://github.com/cifsd-team/ksmbd/issues

BENUE commented on 10.10.2023 04:47

Bonjour, toujours pareil rien a changé : mes fichiers pèse toujours 0 octets sur freebox server delta…

@Tehoden, @eric12, @BENUE : Pourriez-vous faire un ticket ici pour faire avancer la chose ?
- https://github.com/namjaejeon/ksmbd/issues

Dedans il faudrait mettre le lien vers ce ticket et également celui-ci :
- https://dev.freebox.fr/bugs/task/34655
- https://github.com/openwrt/packages/issues/12933

Et faire un nouveau commentaire avec le lien vers ce ticket ?

Il est très important de résoudre ce problème qui existe depuis plusieurs années.

Salut à tous,
, merci pour ta sollicitation. Si tu regardes bien, j'ai justement fait un commentaire, "Tehoden a commenté le 20.07.2023 08:47" où j'expose l'état des lieux sur la dernière version de firmware. Depuis, en ce qui me concerne, pas d'évolution autre.

Je n'ai pas eu le temps de m'occuper d'ouvrir un ticket sur Github pour le moment. Dès que je peux, car il faut le poster au bon endroit, j'étudie cela.

Merci, TeHoDenN.

Admin

spammer le github du project ksmbd ne semble pas très utile (loin de là).

Un ticket est déjà ouvert à ce sujet. A moins d'avoir un moyen de reproduire le problème (auquel cas je vous invite à le partager ici), c'est du bruit.

Avec les informations déjà partagées je ne suis pas arrivé à reproduire le bug pour le corriger.

@mmakassikis: Il n'y a pas de ticket officiel à propos du "0" au niveau du projet officiel ksmbd/ksmbd-tools (ou alors il faut l'indiquer ici), il faut indiquer le problème à la source.

Par contre, il y a bien le ticket pour le problème de caractères, où le développeur principal attend votre retour ^^ : https://github.com/cifsd-team/ksmbd/issues/598.

Puis le ticket pour le support des imprimantes (informations complémentaires demandées) : https://github.com/namjaejeon/ksmbd-tools/issues/172.

Admin
@mmakassikis: Il n'y a pas de ticket officiel à propos du "0" au niveau du projet officiel ksmbd/ksmbd-tools (ou alors il faut l'indiquer ici),

Certe, ce n'est pas sur le projet officiel, mais le bug a déjà été signalé (d'ailleurs vous n'avez pas manqué de me pinguer sur le ticket)

https://github.com/openwrt/packages/issues/12933#issuecomment-1694068605

il faut indiquer le problème à la source.

Le problème est connu, et pour l'instant la lecture du code seule n'a pas permis sa résolution. A moins d'avoir un moyen de reproduction, ouvrir un autre ticket ou renchérir sur un ticket existant ne sert strictement à rien.

@Tehoden, @eric12, @BENUE : Il est important d'expliquer que pour le ticket https://dev.freebox.fr/bugs/task/38504, le fait d'avoir fait le ticket à la source a permis une correction upstream et qui devrait être dans le prochain firmware :
- https://github.com/cifsd-team/ksmbd/issues/598

La preuve que ça permet d'avoir une solution, merci @nxo :)

Il est, je pense, important de faire un ticket là-bas pour le "0".

Est-ce possible de faire une capture/dump/pcap ?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing