Gigablue HD Quad Plus - Problème de lecture des enregistrements

[wile]

Bonjour,

il y a un mois, j'ai remplacé mon Vu+ Solo2 de 2015 par un Gigablue HD Quad Plus d'occasion. Ce dernier enregistre sur le même HDD que celui qui était dans le Vu+, un Seagate de 2 To. Je suis en TT et j'ai mis en fond le concert de la Fête de la Musique de ce samedi soir de France 2, enregistré sur Fransat donc. Sur le Gigablue, la lecture s'interrompt régulièrement. En gros, l'image et le son peuvent se figer 15 secondes et la lecture reprend ensuite plus loin (je rate donc 15 secondes par-ci, 15 secondes par-là). Dans d'autres cas, la lecture se fige mais se débloque par un retour en arrière. J'ai copié le fichier sur mon NAS. Si je lis le même fichier via l'Edision Mio 4K+ à partir du NAS, la lecture est fluide et sans interruption. Il n'y a donc pas eu d'erreur au moment de l'enregistrement. J'avais déjà constaté une problématique de lecture des enregistrements mais à ce moment-là j'avais plusieurs enregistrements simultanés en cours et j'ai éventuellement pensé que j'en demandait trop à l'appareil (3 enregistrements et une lecture). Or ce matin, pas d'enregistrements en cours mais malgré tout ce problème de lecture.

Eventuellement une commande Telnet pour tester la vitesse de lecture du HDD? Ou autre chose? Le HDD est en ext4.

Merci.
wile

[Unix-Linux]

Tu as deux possibilités : soit un problème hardware/software du Gigablue, soit un problème au niveau du HDD

sous "unix like"

code : Tout sélectionner

e2fsck -vf /dev/sda

sous doze :

code : Tout sélectionner

chkdsk "hdd": /r

Essayer un autre HDD ?

[wile]

Voici le résultat de la commande

code : Tout sélectionner

root@gbquadplus:~# e2fsck -vf /dev/sda
e2fsck 1.47.1 (20-May-2024)
/dev/sda is in use.
e2fsck: Cannot continue, aborting.

J'avais déjà un doute auparavant sur le HDD quand il était dans le Vu+ mais ce doute a disparu quad j'ai vu que le Vu+ plantait / redémarrait pour un oui ou pour un non et pas uniquement au début d'un enregistrement.
Je pourrais tenter avec un 320 GB en rab.

[solar10]

fsck indique que ton disque est monté/utilisé.

[Mackguil]

Umount pour démonter le disk

Tu devrais trouver son chemin dans /média ou /mnt

Umount /media/hdd

C'est comme ça qu'était monté le disque dans le temps avec openpli

[cezame]

Umount pour démonter le disk

Tu devrais trouver son chemin dans /média ou /mnt

Umount /media/hdd

C'est comme ça qu'était monté le disque dans le temps avec openpli

Sinon un fdisk -l pour trouver sa dénomination dans/dev

___
CS

[Unix-Linux]

J'ai mis " /dev/sda" mais en fait c'est le premier SSD/HDD utlilisé par l'OS

Donc, comme suggéré au dessus, trouver le HDD via

code : Tout sélectionner

fdisk -l

Ou

code : Tout sélectionner

df -h

Ou encore

code : Tout sélectionner

lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL

Ou encore
==>j'arrête ;-))))~~

[wile]

oui, c'est bien sda (disque de 2 To ---> 1863 GB)

code : Tout sélectionner

root@gbquadplus:/dev# fdisk -l
Disk /dev/sda: 1863 GB, 2000398934016 bytes, 3907029168 sectors
243201 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sda1    0,32,33     1023,254,63       2048 3907028991 3907026944 1863G 83 Linux
root@gbquadplus:/dev#

[solar10]

Donc, tu dois 'démonter' (umount) ton disque avant de le passer à la moulinette fsck.

[wile]

Avec un peu de recul, le problème s'est encore posé mais je pense pouvoir mettre le disque dur hors de cause. J'ai d'ailleurs constaté qu'il fonctionne mieux connecté en USB qu'à l'intérieur.
Il reste donc deux causes possibles :
- soit une mise à jour buggée (ça semble OK sous OpenVix 6.7.012 mais foireux sous la version 6.7.020, qui sera d'ailleurs la dernière version pour ce récepteur)
- soit un problème de plugins : j'ai installé les plugins HDF Radio et AirNet-FNC. Le second, actuellement déinstallé serait en cause.