PDA

View Full Version : HDD/Playback Issues



Silent
26-09-14, 11:52
Hi All

I'm having some problems with internal HDD's in the Quad Plus. After some time it seems to corrupt the HDD's, which I then have to plug into a PC to reformat.

HDD's tried:

Hitachi HTS54321 160GB
Samsung HM500J1 500GB
Toshiba MQ01ABD100 1TB

All tried multiple times each, all corrupted after moderate use. Timeshift used to be enabled, but turning it off hasn't helped at all.

One other issue seems to be play back of recorded programs. The play back of recorded programs skip and jump all over the place regardless of whether it was recorded on a FTA channel or not. The weird part is if you transfer anything to the box, it plays perfectly. Weirder yet, transfer the recorded program off the box to PC, delete it from the box, then transfer back up and it will play back perfectly.

HW/SW info, this has reoccured on various versions of VIX; 022, 023, 032, 037. Currently running on 037. The box was purchased from the sponsor.

Any help would be greatly appreciated.

Just as a side note, I've moved the HDD into a USB enclosure and connected to the USB 3 socket to test that. Should know more later or tomorrow on that.

Thanks
Silent

Joe_90
26-09-14, 16:12
What do you mean by corrupted the HDD? How does the corruption manifest itself? Later versions of ViX (post 024) have a driver issue which causes skips in playback. Well documented in several threads. I'm sticking with 023 until fixed by Gigablue.

leshay
26-09-14, 17:40
Later versions of ViX (post 024) have a driver issue which causes skips in playback. Well documented in several threads. I'm sticking with 023 until fixed by Gigablue.

Hi

Where can I get version 023? I have those playback issues and would like to try 023 to see if it clears that problem. The update site seems to go back to 032.

Silent
26-09-14, 19:02
What do you mean by corrupted the HDD? How does the corruption manifest itself? Later versions of ViX (post 024) have a driver issue which causes skips in playback. Well documented in several threads. I'm sticking with 023 until fixed by Gigablue.

Corrupt meaning can no longer be read by the device. The box doesn't see it and must be plugged into a PC and formatted.

The playback issue was also there in 023 for me, but I did manually update the drivers so it was probably that.

As Leshay says, does anyone know where we can download the 023 image or can somebody post the driver that was originally in 023 so I can restore my backup and put the older driver in play?

Joe_90
26-09-14, 19:58
There's no way an image which works for everyone in the Quad Plus would cause three HDDs to fail on you. You need to address this issue firstly. Seems like a hardware or controller fault. I assume you did initialise the disks in the machine and allow it to format them as ext4? I've had a Quad Plus since April with an internal HDD and it's been through OpenMIPS, OpenATV, OpenRSI and eventually ViX. No issues at all with the HDD. It's not a great idea to be updating drivers independently of the images. When the images are built they include the relevant linux kernel and device drivers. If you mix an image with the wrong drivers, there may be unintended consequences.

I keep copies of the images as they are released, but the problem would be that the relevant plug-ins are not available. There have been significant changes in the images since 025 and also in the way that they are built meaning that the matching plug-in feeds are only available from the most current releases.

What you should do is make complete image copies using the ViX utility in the menu when you have a good working system with your plug-ins and settings right. This consolidates all your data from internal flash into one package file on disk. Then you can always revert to them as a complete package if you run into issues with a later release.

I would suggest you contact WoS and consider having the box checked over for hardware issues.

Sicilian
27-09-14, 19:51
I'll upload 023 tomorrow.


Sent from my iPhone using Tapatalk

Silent
28-09-14, 12:54
Just as an update - there are no playback issues at all with the HDD connected by USB after playing back about 6 hours worth of recorded material.

The reason for the driver update was for the transcoding, as I live 5000KM away from where the box is in the UK so being able to transcode Sky Sports is nice.

Will leave it on 037 and USB for now. When Gigablue fix it we will try with it in the box again. If it corrupts I'll contact the seller, we still have about 10 months on the warranty to go.

hilly
28-09-14, 20:24
What do you mean by corrupted the HDD? How does the corruption manifest itself? Later versions of ViX (post 024) have a driver issue which causes skips in playback. Well documented in several threads. I'm sticking with 023 until fixed by Gigablue.

040 has fixed this issue as just watched 2 Scott and bailey episodes with no issues.Thanks team as was getting grief from her.

Joe_90
03-10-14, 14:39
I decided that I had better get on a newer image because on 023 I wasn't able to add any plugins I wanted to test as they had been removed from the feeds. I was on 023 because any other image post 024 was causing playback stutters on my recordings. All documented over on the ATV forum and was due to memory over-use. I had tried 037 briefly but I had the same issue.

Just loaded 041 last night and I also installed the cacheflush plugin which I reckoned I would need to resolve the memory usage issue. However, I was pleased to see that I haven't needed the plugin so far as the memory issue seems to have been resolved. Before, I could see the free memory on the box fall as low as about 2MB and then the playback stutters began. I've tested now for several hours with four recordings running while I played back the F1 practice recorded earlier on BBC1 HD. No playback issues and free memory stayed at 28MB - 30MB at minimum. I'm not sure exactly what has changed in the code to fix this, but I'm optimistic that the issue has gone away for now. There is still an issue with the LCD on the box as it flickers during boot up and the display is operating at full brightness even in standby but this is definitely a driver problem.

amspa
04-10-14, 18:18
fat-tony,

I've upgraded my box now to version 41 but I'm still getting the playback issue with it eating all the memory and then stuttering. Free memory is getting down to 2 or 3MB.

Was there anything else you changed to get it working?

Thanks

Joe_90
05-10-14, 00:45
No - I did a clean flash install. No settings restores. I'm on the new bootloader, but have been on that since 025 and I never went back to the older bootloader even when I reverted to ViX 023.

As I said I did install the cacheflush plugin and played with it for a while and then disabled it (but did not uninstall it). 041 working perfectly fine for me. Free memory never goes below about 28MB. Not a stutter all day today and have watched loads of recordings.

amspa
05-10-14, 09:23
Thanks for the reply.

The only difference for me is that I did an update from version 40 rather than a complete flash. Not sure if that would make any difference.

I'll try a clean flash and see if that sorts it.

Thanks again

Joe_90
05-10-14, 12:59
Thanks for the reply.

The only difference for me is that I did an update from version 40 rather than a complete flash. Not sure if that would make any difference.

I'll try a clean flash and see if that sorts it.

Thanks again

I did some more playing about with the cacheflush plugin. I'm wondering now if, despite the fact that it's now inactive, whether running it once initialised a system parameter which maintains a minimum level of uncached memory? Just now I started cacheflush and set the minimum uncached memory to 1024 (kB) and saved. Then I started cacheflush again and set it to inactive and saved again. I then started a couple of recordings and started watching back another and could see the cached memory grow and grow until only about 1MB of memory was free. No stutters. I then started cacheflush again and set the minimum uncached memory to 20480 (kB) and saved. Then went in again and inactivated cacheflush and saved. The system seems to remember the setting and retains over 20MB of uncached memory at all times.

I would suggest you download cacheflush 1.17 from the plugins and try it. Set the minimum uncached to 20480 and save. Afterwards you can go in and turn off cacheflush and presumably the system minimum will "stick". It's worth a try until Gigablue sort out what's eating all the memory.

amspa
08-10-14, 09:17
Thanks, I'll give it a go.

Joe_90
08-10-14, 11:54
Thanks, I'll give it a go.

It seems to be working for @leshay who has been having playback issues.

amspa
08-10-14, 11:54
fat-tony,

I've just tried what you suggested and it does indeed seem to correct the memory-related playback problem.

Thanks a lot!!

BTW I'm running version 043

Joe_90
17-10-14, 00:05
In the past 10 days or so, there have been some changes to the way the GB Quad Plus memory management settings are applied. From trawling around on the OpenMIPS and OpenATV forums the following settings are now applied to the Quad Plus:


vm.dirty_writeback_centisecs = 300
vm.dirty_background_ratio = 1
vm.min_free_kbytes=8192
vm.dirty_ratio = 60
vm.swappiness = 30



This has, among other things, the result is that more RAM is left open (~ 6M with min_free_kbytes = 4075, ~ 12M with min_free_kbytes = 8192). 2nd For Gigablue is now set in the defconfigs 'CONFIG_CMDLINE_OVERRIDE' ( https://github.com/oe-alliance/oe-al...4e8a299ae1644f ), which also influences the type of memory management. third For Gigablue's been a change in the driver. The thanks again Arn354

Basically the default settings in the box now allocate a minimum of 8MB free memory which should eliminate the issue of glitching in playback of recorded material. You should no longer require to use the cacheflush plugin as the new default settings should provide adequate free memory. If you flash with the latest ViX image you will get the new settings and also an upgraded set of Gigablue drivers which resolve the issue of the brightness control on the LCD not working and apparently transcoding should now work, though I've yet to test this.