[VU+ Duo] Problems with ViX 2.3 crashes and using USB memory, read this first

[Zartmy]

Some USB memorys cant handle the new code introduced to put external USB harddrives to sleep. This causes usb memorys to go to permanent sleep with filecorruptions and crashes as result.

Test to see if you are affected (run in telnet session)
Run the command sfdisk -l /dev/sd? if that returns an empty partiontable for a device that was working before, run the following command sdparm --readonly --flexible --command=start /dev/sd? then try sfdisk -l /dev/sd? again. If you got output the second time the workaround should fix your problem.

Workaround

1. chmod 000 /usr/bin/sdparm
2. Reboot
3. If you can access the files, save them to a safe place
4. Reformat your usb stick in the ViX menu
5. Reboot

If the above helped post to this thread the following information
1) Brand, modell name and size of the stick
2) Output from lsusb

Might be good to make this one Sticky...

 

[Zartmy]

Just realised that you can trigger the bug manually before running sfdisk -l /dev/sd? the first time. Run sdparm --readonly --flexible --command=stop /dev/sd? before the first run of sfdisk, if the usb memory functions normally it should start up when running sfdisk.

 

[Sicilian]

Just to be clear, VIX Team have not introduced any new code, maybe PLi has, not sure.. If anyone is having issues with a certain USB stick and the above suggestion does not work I'd recommend using a different make/model of USB stick. Also ensure that its not some cheap clone USB stick from fleabay, only use quality USB Sticks.

Initialize in the receiver, menu > setup > system > hard disk > Initialize. To view progress press blue button > select the progress by pressing OK and it will switch to job view. Once initialized check in mount manager. Blue button > VIX > Mount Manager. Ensure the USB stick is mounted to /media/usb then reboot by holding down standby button and selecting restart.

 

[Rimmel]

Some USB memorys cant handle the new code introduced to put external USB harddrives to sleep. This causes usb memorys to go to permanent sleep with filecorruptions and crashes as result.

Test to see if you are affected (run in telnet session)
Run the command sfdisk -l /dev/sd? if that returns an empty partiontable for a device that was working before, run the following command sdparm --readonly --flexible --command=start /dev/sd? then try sfdisk -l /dev/sd? again. If you got output the second time the workaround should fix your problem.

Workaround

1. chmod 000 /usr/bin/sdparm
2. Reboot
3. If you can access the files, save them to a safe place
4. Reformat your usb stick in the ViX menu
5. Reboot

If the above helped post to this thread the following information
1) Brand, modell name and size of the stick
2) Output from lsusb

Might be good to make this one Sticky...

Could you let us know how this work-around fixes the problem please?

thanks

 

[Zartmy]

In Enigma2 Harddisk.py registers a callback thats periodically check if the disk is in use, if it thinks its not in use it calls sdparm with the code in post2. All disks whoose pathway in /sys does not includes the string pci is considered external disks, the others internal and are called with hdparm instead. So setting the rights on /usr/bin/sdparm to 000 means that no one can read,write or execute the file, thus when the code in Harddisk.py tries to set external drives to sleep, the call to sdparm will silently fail. This also means that reverting the workaround is as simple as chmod u=rwx,og+rx /usr/bin/sdparm

 

[edogg]

Some USB memorys cant handle the new code introduced to put external USB harddrives to sleep. This causes usb memorys to go to permanent sleep with filecorruptions and crashes as result.

Test to see if you are affected (run in telnet session)
Run the command sfdisk -l /dev/sd? if that returns an empty partiontable for a device that was working before, run the following command sdparm --readonly --flexible --command=start /dev/sd? then try sfdisk -l /dev/sd? again. If you got output the second time the workaround should fix your problem.

Workaround

1. chmod 000 /usr/bin/sdparm
2. Reboot
3. If you can access the files, save them to a safe place
4. Reformat your usb stick in the ViX menu
5. Reboot

If the above helped post to this thread the following information
1) Brand, modell name and size of the stick
2) Output from lsusb

Might be good to make this one Sticky...

hi I think this has cured my mount problems it has not un-mounted my usb medion 128mb usb1 memory stick since following these instructions however i get usb not found when issuing the command -lsusb

 

[Zartmy]

i get usb not found when issuing the command -lsusb

lsusb as one word, no space between ls and usb.

 

[edogg]

lsusb as one word, no space between ls and usb.

I type -lsusb it responds lsusb: not found
i type lsusb it responds
Bus 004 Device 001: ID 1dób:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1dób:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1dób:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1dób: 0117:0117
Bus 001 Device 001: ID 1dób: 0002 Linux Foundation 2.0 root hub

this is how it appears on screen and is exactly how i have typed the commands

 

[edogg]

the usb is definitely cured with this fix i had absolutely no un-mount problems since applying it thanks for the fix Zartmy

 

[Zartmy]

the usb is definitely cured with this fix i had absolutely no un-mount problems since applying it thanks for the fix Zartmy

Good to hear edogg, I wouldnt be surprised if most of the cases where ppl have problem with there EPG downloads is a indirect result of there usb-sticks being messed up. If you have had one occasion where the usb stick has been put to sleep the filesystem is pretty much ****ed up, it works a while until it doesnt get mounted on boot anymore. Then they fill up there internal flash instead.

So if one try to chmod sdparm, be sure to reformat your usb-stick after and reboot.

 

[Rob van der Does]

There is indeed a kernel bug in kernel 3.x, resulting in setting all USB-storage devices to standby. Not all devices are affected by this: on many the firmware of the stick prevents this.
An easy work-around is to set HDD-idle time to 'never'.

 

[wazza_2]

or just go to ; menu , setup, system, harddisk, harddisk setup, no standby. then restart your box to take afect, worked for me mine and most others will be set as standby after 5 min

 

[mcquaim]

or just go to ; menu , setup, system, harddisk, harddisk setup, no standby. then restart your box to take afect, worked for me mine and most others will be set as standby after 5 min

Surely this would just leave your HDD spinning constantly? If you don't have PTS enabled then no need for it to be spinning away...

 

[Rob van der Does]

Well, HDD are made to be running, not to sit still. Mine never stops.

Anyway: the next update will have a fix for USB-sticks going to sleep.

 

[stevesom]

I have done the above by zartmy and it seems to have worked i had constant crashes on start up with the epg on my usb stick until i follwed the instructions in the first post.
iboutique 32gb usb drive
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 090c:1000 Feiya Technology Corp. Flash Drive
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Any changes and i will update you
cheers
steve