Recording / playback glitches, reproducible on two separate Gigablue boxes

[steveharman]

This issue relates to two entirely separate Gigablue Quad boxes at different locations, but the symptoms are the same. Both boxes run the latest OpenVix version but the problem has been observed for about six months regardless of Vix version.


Gigablue Quad HD
Internal SSD
Latest OpenVix


Gigablue Quad HD+
Internal HD
Latest OpenVix

99.9% of the time when recordings are played back they will freeze regularly. The "fix" is to leap back a few seconds with the "1" button on the remote and then playback will continue fine across the section of the recording that it froze at previously for another 5 or 10 minutes, and then the same thing will happen again. It's not as it the recordings themselves seem to have been corrupted when made, as fas as I can tell, because as noted - jumping back a few seconds and resuming playback again passes the sections where freezing happened the first time.

This happens whether the recordings are made from satellite (28.2E) or IPTV. The boxes are at different locations with different internal HD technologies. At one point I even removed our SSD & reformatted it just for the hell of it - made no difference.

The interesting thing is that if we make recordings to a NAS over the LAN - the playback problem never seems to happen. I'd have suspected the internal drive was playing up were it not for the fact that it's happening to us & our inlaws and we have different boxes of different ages with different types of drive installed.

Does anyone have any suggestions or ideas?

Thanks,

Steve

[twol]

There is a similar thread elsewhere and the solution appears to be install cacheflush plugin from the feeds - perhaps try and see?

[Joe_90]

Try doing a couch flash/usb flash of Vix 5.3.002 followed by a settings restore. Some GigaBlue-specific data in /etc/sysctl.conf seems to have been dropped in previous releases and has now been reinstated (thanks @twol). It provides for some extra memory headroom, similar to what cacheflush was doing. I've been testing the amended settings for a couple of weeks now (without cacheflush) and have had no issues with playback.

[steveharman]

Try doing a couch flash/usb flash of Vix 5.3.002 followed by a settings restore. Some GigaBlue-specific data in /etc/sysctl.conf seems to have been dropped in previous releases and has now been reinstated. It provides for some extra memory headroom, similar to what cacheflush was doing. I've been testing the amended settings for a couple of weeks now (without cacheflush) and have had no issues with playback.

Thanks Tony. I'll give that a try. cacheflush seems to have resolved the issue but I'd prefer to have a "native" resolution as per your suggestion.

Cheers,

Steve

[Joe_90]

Steve,

The actual changes are the following lines appended to /etc/sysctl.conf, which used to be there but disappeared several builds back. The new builds have restored these settings.


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

The key setting seems to be vm.min_free_kybtes

If you flash the newest build and try uninstalling the cacheflush plugin and let us know how you get on it would be appreciated.

[steveharman]

I'll try at lunchtime today @fat-tony - I dont mind sacrificing Bargain Hunt for the good of the cause. ;-)

Thanks again