hulster

Installing glass-hd causes this problem. Even if you do not select the skin, just having it installed, and you'll run into these kinds of problems.

BTW, uninstalling won't fix it, the glass-hd skin has done permanent damage to your system files.
A clean flash is required.

I ran into a similar issue a few weeks ago where glass-hd causes a GS when go to filelist. A developer recommended to uninstall it and re-intall just the sources as packet. This overwrites the by glass-hd overwritten python files.
That works for me. Search for my posts if you like, you can find the thread where I mentioned that works for me.

Workaround works for me as well.
By that I tried Skin PLi-HD. That does not look that bad. Will try it for a while

I don't see it that way. It does not work like a democracy. If there are a thousand reports that some setting "fixes" the issue, and only one that it does not, then my conclusion is that it does NOT fix the issue.

If the ext4 driver alone is the issue, then mounting with the ext3 driver should work just as well, because we've been using that for ages now. But it doesn't. The root cause of the problem is in the kernel somewhere. It is triggered by a combination of factors, the journal is a major contributor, but also delayed allocation and probably the IO scheduler play important roles too. It's not limited to ext filesystems either, the btrfs filesystem performed even worse.

Hi MiLo,

Thx for not ignoring me. Would be great to get a comment just regarding my guess about the priority of processes.

In general, especially for other users: Indeed EXT2 makes it MUCH better and I didn't said that there is no other issue. That there is MAYBE ANOTHER issue I tried to point out.
So my intention was to state EXT2 helps a lot, but MAYBE not for everything/everyone.
Just additionally - I have not too much plugins installed - especially no EMC. Skin HDGlass16.

@hulster
Did you install the ext2-kernel-module and did you create an entry in /etc/fstab for mounting your hdd?

If you use ext2 with automount (no change in /etc/fstab), your hdd will be mounted with the ext4-kernel-module, which is default.

All users who have tested the ext2 filesystem reported freezers when they were using the default ext4-kernel-module.

This ext2 workaround will only have a positive effect, if you use the ext2-kernel-module.

Thx - but known. That is why I mentioned ext2 VERIFIED. "mount" output clearly tells ext2. And yes kernel module installed and fstab entried made.

A totally different guess: I am still experiencing glitches/freezer running verfied EXT2. My disk is 500 GB, so no issues with sector size. Joining the discussion in the vendor forum I was always wondering, that there is no real distinct behavior. Even EXT4 seems to be an significant factor, it seems not be the only one.
So what about if in the 3.x the thread handling or process priorisation is different. Or maybe just the priorisation of the recording processes by new PLi build.
For me it looks currently that everything ressource grabbing could have a negative affect to recordings. Some stuff more due to higher resource needs some other less.
So if the priority for recordings running in background has changed to lower for some reason, this could explain some of the behavior and especially not every proposal/chenge works the same for everybody.
Just an idea - which MiLo may wipe out easily.