Your comments

Même si ce n'est pas forcément prévu pour cela, la mise en place du mode bridge pour un seul appareil n'est pas très différente par rapport à plusieurs appareils :

  • pour plusieurs appareils : on place un routeur additionnel en mode bridge sur la box (puis on connectera tous les appareils derrière ce routeur)
  • pour un seul appareil : c'est cet unique appareil qu'on place en mode bridge sur la box (à la place du routeur en somme)

Et, dans chacun des 2 cas ci-dessus, pour placer sur la box un élément en mode bridge (que ce soit le routeur ou directement l'appareil unique) suivre cette procédure de la doc Numericable (hélas disparue désormais) ou s'inspirer de celle-ci de la doc SFR.


La version Android de LaBox TV présente aussi cette invitation à passer à SFR TV :



D'ailleurs, les multiples langues de sous-titres sont aussi problématiques avec les vidéo AVI car, concernant ce format, le Media Center impose que le fichier SRT de sous-titres porte exactement le même nom que la vidéo (avec SRT en suffixe à la place de celui de la vidéo).

Cette limitation a des conséquences gênantes :

  • la box ignore alors totalement le sous-titrage d'une vidéo "MaVideo.AVI" même si l'unique fichier de sous-titrage respecte un nommage assez standard pour indiquer la langue : MaVideo.fr.SRT"
  • la box ne peut pas déduire du nom standard du fichier de sous-titrage la langue contenue (actuellement elle indique seulement SRT là où elle réussit au contraire à indiquer correctement la langue des sous-titres d'un MKV)
  • un seul nom de sous-titrage accepté rend évidemment impossible d'avoir plusieurs fichiers SRT de langues de sous-titrages (MaVideo.fr.SRT, MaVideo.en.SRT, etc.)

Pourtant, ces nommages standard sont très répandus (par exemple le lecteur VLC les prend en compte et indique ainsi les sous-titrages multiples disponibles et leurs langues associées). Il serait très pratique que la box prenne aussi en compte le même nommage standard.

En effet, on aimerait ce genre de fonctions qui existent déjà depuis longtemps chez la concurrence :

  • filtrage des appels par numéros ou par préfixe (à travailler par l'abonné)
  • blocage automatique d'appels indésirables via une liste mise à jour par l'opérateur (pour éviter du travail à l'abonné)
  • ... :-)

Normalement il n'y a plus eu de mise à jour de cette appli LaBox TV depuis des mois (presque des années). Elle n'est d'ailleurs plus proposée au téléchargement sur le store Apple (iOS) ou Google (Android).


  • Elle a d'abord semblé implicitement remplacée au profit de SFR TV depuis la réunion Numericable-SFR puisque les abonnés Numericable ont depuis longtemps constaté que leurs identifiants étaient désormais prévus et acceptés comme ceux de SFR dans cette autre appli
  • Peu à peu certaines des fonctions de LaBox TV sont devenues incompatibles avec les évolutions chez Numericable-SFR
  • Elle semble donc clairement abandonnée (plus de mise à jour, plus disponible au téléchargement) même si des utilisateurs ont continué à l'utiliser. D'ailleurs sur la version iOS (mais pas Android semble-t-il) la chose est claire depuis des mois puisqu'une alerte dès le lancement invite à quitter LaBox TV pour passer à SFR TV



Bref, même si cela n'a pas été annoncé par Numericable, il semble acté que c'est désormais vers l'appli SFR TV aux fonctionnalités similaires qu'il faut s'orienter.


Raisonnable dénouement : finalement notre fournisseur a pensé que Netflix pouvait bien être complémentaire de son offre SFR play, et depuis le mardi 13 juin Netflix est arrivé dans notre univers ! Désormais les intéressés par Netflix peuvent :

  • voir les contenus Netflix directement sur les modèles les plus récents de box SFR :
    box 4K (FTTLA câble) ou aussi décodeur Plus (FTTH)
  • souscrire via SFR pour avoir la facture Netflix intégrée à la facture SFR (qu'on ait un décodeur compatible ou non)

Il ne manque plus qu'à décliner cette fonction aussi sur les modèles de box V1/V2.

Bonjour,

Honnêtement SMB ne serait pas forcément « l'idéal » comme vous semblez l'écrire.

Certes SMB est très pratique (surtout pour les Windowsiens) sur un réseau local, c'est pourquoi l'autre demande citée est tout à fait légitime.


Cependant, à distance depuis internet comme abordé dans notre discussion, SMB n'est pas vraiment un protocole ni recommandé, ni performant (cf. de nombreuses discussions comme celle-là par exemple).

Pire, sur nos box câble, SMB est pour l'instant ouvert en mode « invité », càd sans même nécessiter de mot de passe pour accéder au contenu, ce qui n'est pas du tout adapté à un usage à distance.


Bref, les 2 demandes (celle de cette discussion sur FTP, et l'autre que vous citez sur SMB) ont leur utilité et sont absentes depuis déjà très longtemps hélas.

Oui, pour une ouverture du serveur FTP de la box vers l'extérieur, il faudrait ab-so-lu-ment pouvoir personnaliser l'identifiant, sinon point de sécurité.


De plus, il faudrait que le serveur FTP interne accepte les requêtes SSL (pour faire du FTPS) car sinon, même personnalisés, les identifiants passeraient en clair sur internet, ruinant les efforts de sécurité.

Il semble d'ailleurs étonnant que SSL ne soit pas accepté par le serveur ftp interne de la box car :

  • le serveur ftp utilisé dans la box est vsFTPd 3.0.2 (affiché à la connexion)
  • ce serveur permet les requêtes SSL si on l'active bien dans la configuration (cf. la FAQ qui le confirme) :
Q) Does vsftpd support SSL / TLS based encryption?
A) Yes, as of v2.0.0, this is supported for the control and data connections
(hurrah). You need a build of vsftpd with this support enabled, and then you
need to activate the ssl_enable setting.


Merci à notre fournisseur de régler ces 2 petits détails (prendre en compte la personnalisation de l'identifiant, et activer le support SSL dans vsFTPd) afin de donner à la fonction FTP intégrée les bases de sécurisation.

Il est vrai qu'il est décevant que la version antérieure tolère bien ce caractère "spécial" et qu'au contraire cela plante dans la nouvelle version de la box 4K (d'ailleurs d'autres caractères spéciaux semblent aussi provoquer le même problème).


Cependant j'ai bien peur que le correctif ne soit pas une priorité avant longtemps car les "saines recommandations" pour nommer des fichiers et dossiers partagés sur réseau et web invitent justement à éviter ce genre de caractères, (pour se prémunir de ces désagréments un peu cachés, mais bien problématiques quand ils surviennent) => lire ici par exemple.


Il y a aussi des caractères possibles dans certains systèmes de fichiers mais interdits dans d'autres. Par exemple le ' / ' interdit sous Linux, mais possible pour les noms courts en FAT16/32 (mais pas pour les noms longs), dans d'autres c'est le ' : ' qui est rigoureusement interdit... => lire ici.


C'est sans doute un peu pour ces risques que l'ancestral dossier des objets trouvés (Lost and Found) de Unix/Linux a choisi le '+' et non pas le '&' : lost+found.