|
||||||||
HDR Hard Drive slowing down through Fragmented files? |
![]() |
|
|
Thread Tools | Search this Thread |
|
|
#26 |
|
Forum Member
Join Date: Jan 2006
Location: Fife
Posts: 4,038
|
Quote:
Honestly, I've no clue what the hell they are doing when they delete a file.
The amount of time it takes they could be defragmenting the drive as they go. ![]() They're certainly doing something pretty stupid and I hope they sort it out for the next update. Quote:
No one called anyone stupid and its comments like that that are ignorant. The whole point of a forum is to discuss and debate problems not just write something off because convention says its impossible.
Quote:
...and if you read the link to the Linux file system posted earlier then you'll have noted that the system breaks down into fragmentation when the hard drive is more than 80% full. EXT3 fs reserves diskspace for when the filesystem approach to being full to deal with 'squeezing the last bit of storage' on to the disk. Fragmentation is not an issue on non-Windows filesystems.Thats hardly difficult to achieve on a 320GB drive. I had mine 96% full of files I wanted to keep permanently within 3 weeks of buying the box in November. Quote:
I actually have a 1TB WD PVR drive in now but since hitting around 35% full I seem to be noticing a slow down in box response (playback and recording are perfectly ok just commands).
I have a 1TB WD hard disk in my HDR - it is 70% full, I have not experienced any 'slow response via remote control commands'.Quote:
My remote has always been immediate in response (albeit sometimes from angles it didn't get picked up). Now theres a 1 or 2 second delay between pressing the button and the cursor responding. Similarly when changing channels, if you change quickly in the EPG it easy to overshoot your target channel as the channel indicator lags behind the down / up button presses so you press quickly, it moves, you stop when you think you're on the right channel and a second later after you've stopped it goes right past to next channel.
I don't know what your problem is, but there are times when the box is overly worked (e.g. right after boot-up, recording 2 and playing back a recording, etc), and at these time, there is a noticeable slower response via the remote.
|
|
|
|
|
Please sign in or register to remove this advertisement.
|
|
|
#27 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
I refer you to the above statement! Are you trying to speak for everyone..?
Just to reitterate to give you one more chance of understanding: Person does something stupid != Person is stupid. It's called 'human falibility'. You really need to take a chill pill. ![]() Quote:
EXT3 fs reserves diskspace for when the filesystem approach to being full to deal with 'squeezing the last bit of storage' on to the disk. Fragmentation is not an issue on non-Windows filesystems.
I fear you are talking way outside the limits of your knowledge here.I have worked on many non-Windows systems that have most definitely suffered with fragmentation problems. Designing a file system is a very compleex set of tradeoffs between speed, effiecienct use of storage, resiliance and need for routine maintenance. Quote:
I don't know what your problem is,
Indeed. Let's just hope that Humax figure it out.
|
|
|
|
|
|
#28 |
|
Forum Member
Join Date: Jan 2006
Location: Fife
Posts: 4,038
|
Quote:
As I said earlier: "You also need to realise that even the best systems engineers do stupid things at times. Most of us on a daily basis! Occasionaly one of our stupid decisions gets out into the wild and has to be corrected at a later stage".
Just to reitterate to give you one more chance of understanding: Person does something stupid != Person is stupid. It's called 'human falibility'. You really need to take a chill pill. ![]() Quote:
I fear you are talking way outside the limits of your knowledge here. Hahaha, you've must have worked on some pretty mickey mouse systems, hey?!I have worked on many non-Windows systems that have most definitely suffered with fragmentation problems. Quote:
Designing a file system is a very compleex set of tradeoffs between speed, effiecienct use of storage, resiliance and need for routine maintenance.
Yes, bring in other issues to 'consolidate' your knowledge! (and obfuscate the real issue )
|
|
|
|
|
|
#29 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
Just withdrawing the statement and saying sorry would suffice. No needed to make up more or 'expand' to cover up your initial rudeness...
Hahaha, you've must have worked on some pretty mickey mouse systems, hey?! Yes, bring in other issues to 'consolidate' your knowledge! (and obfuscate the real issue )I'm afraid that no matter how much it upsets you: 1) There are some stupid aspects to the way the Humax behaves. 2) If you have any breadth of experience with computers you will know that most file systems suffer from fragmentation to some extent. 3) Designing a file system is a very complex set of tradeoffs between speed, efficient use of storage, resilience and need for routine maintenance. The fact that you don't understand all these terms and the tradeoffs involved and so cannot continue your naive and simplistic argument is unfortunate for you but does not make these factors irrelevant. Becoming belligerent in an attempt to handle holes in your knowledge will not impress anyone. |
|
|
|
|
|
#30 |
|
Forum Member
Join Date: Jan 2006
Location: Fife
Posts: 4,038
|
Good grief! Such an expert on systems - your talent is wasted posting in dead end forums like this!
![]() Stick to the relevant topic - we are not talking about general mickey mouse systems - we are talking about the HDR. If you want to expand further, stick to PVRs... *No defragmenation needed* |
|
|
|
|
|
#31 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
Good grief! Such an expert on systems - your talent is wasted posting in dead end forums like this!
![]() Stick to the relevant topic - we are not talking about general mickey mouse systems - we are talking about the HDR. If you want to expand further, stick to PVRs... *No defragmenation needed* I have no intention of coming down to your level. I have said all along that fragmentation should not be an issue for a PVR (assuming basic competence on the part of the design engineers). That is true no matter what file system is in use. That is something you would understand if you knew a little bit more about the things that you seem to think are irrelevant. |
|
|
|
|
|
#32 |
|
Forum Member
Join Date: Nov 2006
Posts: 107
|
Quote:
I sold my Tivo when I got the Humax, but the problem you refer to here was tio to the small amount of RAM in the Tivo. The more you asked it to do the slower the epg etc got as it needed to keep clearing and loading the RAM. I'm not convinced that this is a problem on the Humax as it appears to have plenty of RAM for the job.
There's no real problem with the remote on the Humax - I think it's ALL related to the narrow viewing angle of the sensor due to it being behind the front panel. Mine sits hidden behind the side of the sofa so i have a Keene IR repeater with the receiver under the TV screen and a transmitter stuck to each of my bits of kit. As a result I have no remote issues whether using the Hummy remote or my Harmony. Not an ideal solution but it does work. If people are having remote problems i'd recommend leaving the front panel open and seeing if they still occur. I do have problems with bugs in the Hummy - another lock up/power cycle when i tried switching out of standby as it was waking up to record Mad Men on BBCHD the other day - but no longer have remote issues |
|
|
|
|
|
#33 |
|
Forum Member
Join Date: Jan 2006
Location: Fife
Posts: 4,038
|
Quote:
I have said all along that fragmentation should not be an issue for a PVR (assuming basic competence on the part of the design engineers). That is true no matter what file system is in use. That is something you would understand if you knew a little bit more about the things that you seem to think are irrelevant.
Have you heard of the Moglex expression? Or should I go and defrag the ZFS hard disk in my Sun?
|
|
|
|
|
|
#34 |
|
Forum Member
Join Date: Apr 2008
Location: Devon
Posts: 103
|
Quote:
....... I suspect you were being rude just for trolling purposes!?!
son-t I think you are wasting your time because in my view this member specialises in always being right and can't ever accept there might be a correct alternative view. The simple fact is that Linux file systems do not suffer from fragmentation in the same way as windows systems |
|
|
|
|
|
#35 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
Aha! Coming full circle to the crux of the problem, if you're such an expert on filesystems, then how come you don't know what the HDR is doing when it deletes a file?! I suspect you were being rude just for trolling purposes!?!
Have you heard of the Moglex expression? Or should I go and defrag the ZFS hard disk in my Sun? ![]() If you actually understood what you were talking about and have some knowledge of how an FS is put together you would understand that using a non-fragmenting FS actually does nothing more than move the overhead required to keep the disk unfragmented from being something that is done at a time of the user's choice to something that is done when files are written or deleted. Really, there is no need to get so aggressive just because you don't understand the deeper internals of FS architechture.
|
|
|
|
|
|
#36 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
Spot on.
son-t I think you are wasting your time because in my view this member specialises in always being right and can't ever accept there might be a correct alternative view. The simple fact is that Linux file systems do not suffer from fragmentation in the same way as windows systems It seems that it is you and son_t who are determined to make an argument where there is no disagreement. |
|
|
|
|
|
#37 |
|
Forum Member
Join Date: Sep 2006
Location: S Yorks
Posts: 367
|
Quote:
Spot on.
son-t I think you are wasting your time because in my view this member specialises in always being right and can't ever accept there might be a correct alternative view. The simple fact is that Linux file systems do not suffer from fragmentation in the same way as windows systems http://www.kdedevelopers.org/node/2270 The old argument about "*nix doesn't suffer from fragmentation" used to be that if you had 20 users accessing 20 files then even if the disk files were linear (contiguous) it wouldn't make any difference to performance because the read heads would be jumping anyway! ![]() With a single user system (3 user?) like the HDR possibly writing two files and reading a third simultaneously, all you need is for the read and write heads to get from one block to the next within one revolution, plus a fast enough processor. |
|
|
|
|
|
#38 |
|
Forum Member
Join Date: Apr 2005
Location: Surrey, UK
Posts: 1,302
|
I don't want to get involved in any of the arguments here but I will make some simple clarifications:
* Deleting files in the background is possible, however it presents many challenges. The simplest and most obvious of which is how to deal with the "space available" graph, people will either complain that it hasn't changed (because the delete hasn't happened yet) or if we do change the graph there could be issues where someone wants to transfer/record something and there isn't the space available. The simplest solution, at present, is to delete in real time. * Remember, unlike a computer the software for the Foxsat-HDR does not reside on the hard disk, only A/V content and a cache of the EPG. Any slow down in the user interface is due to some intensive task being run in the background, possibly an SI process or schedule update. |
|
|
|
|
#39 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
I don't want to get involved in any of the arguments here but I will make some simple clarifications:
* Deleting files in the background is possible, however it presents many challenges. The simplest and most obvious of which is how to deal with the "space available" graph, people will either complain that it hasn't changed (because the delete hasn't happened yet) or if we do change the graph there could be issues where someone wants to transfer/record something and there isn't the space available. The simplest solution, at present, is to delete in real time. I think I can see where the delete problems are coming from and I don't now expect anything major to change on that front in the upcoming update. The one thing you could do is to allow us to mark files for deletion and then, when the box isn't recording provide a command to delete all tagged files. Not an absolutely perfect resolution but one that would be easy to implement and a big improvement on what we have now. |
|
|
|
|
|
#40 |
|
Forum Member
Join Date: Apr 2008
Location: Devon
Posts: 103
|
Quote:
The one thing you could do is to allow us to mark files for deletion and then, when the box isn't recording provide a command to delete all tagged files.
If you can't remember what programmes you have already watched you could create a folder called 'Delete' and transfer any recording you want to delete to that folder by using the file manager. Next time you turn the box on just go to that folder and delete the programmes
|
|
|
|
|
|
#41 |
|
Forum Member
Join Date: Oct 2008
Location: Worcester
Posts: 4,185
|
deleted... must get my facts right befrore posting
|
|
|
|
|
|
#42 |
|
Forum Member
Join Date: Dec 2008
Posts: 2,494
|
Quote:
* Remember, unlike a computer the software for the Foxsat-HDR does not reside on the hard disk, only A/V content and a cache of the EPG. Any slow down in the user interface is due to some intensive task being run in the background, possibly an SI process or schedule update.
Must admit, would still feel happier if could rearrange the hard drive after a lot of deletes though. The Linux usn't affected argument still doesn't have me convinced. I accept its better than Windows but I doubt its infallible especially with a lot of data stored and at least 1 web site suggested this to be the case as it approaches full. |
|
|
|
|
|
#43 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
Must admit, would still feel happier if could rearrange the hard drive after a lot of deletes though. The Linux usn't affected argument still doesn't have me convinced. I accept its better than Windows but I doubt its infallible especially with a lot of data stored and at least 1 web site suggested this to be the case as it approaches full.
However, because fragmentation is not such an issue there has been no move to produce defragmentation programs such as are available for windows. The normal method is to write the entire FS to some other device, 'format' the drive and copy the data back again. (This is actually the best way to completely defragment an NTFS drive). Whilst such a scheme could work on this box using the external drive it's hardly likely to be something many people would attempt as it would take a considerable amount of time and only really be suitable for very tech-savvy users. Nontheless, you can rest assured that fragmentation is not going to be an issue on a PVR (unless the designers have screwed up big time) because of the extremely large allocation block size that can be used. |
|
|
|
|
|
#44 |
|
Forum Member
Join Date: Nov 2008
Location: Co. Donegal
Posts: 797
|
Quote:
Despite what certain posters have maintained, Unix is not immune to fragmentation problems, especially when the disk becomes near full.
However, because fragmentation is not such an issue there has been no move to produce defragmentation programs such as are available for windows. The normal method is to write the entire FS to some other device, 'format' the drive and copy the data back again. (This is actually the best way to completely defragment an NTFS drive). Whilst such a scheme could work on this box using the external drive it's hardly likely to be something many people would attempt as it would take a considerable amount of time and only really be suitable for very tech-savvy users. Nonetheless, you can rest assured that fragmentation is not going to be an issue on a PVR (unless the designers have screwed up big time) because of the extremely large allocation block size that can be used. I suppose one difference between a PVR and a Linux PC is life expectancy. There's a very good chance that a Linux PC is going to get upgraded or replaced before defragmentation ever approaches becoming an issue. The HDD getting anywhere near full would be a good reason to change the disk for a bigger one. On the other hand, PVRs should go on for years and could have been full many times during their life. Consequently they could be more vulnerable than Linux PCs to becoming fragmented. Another difference between PC and PVR is that, with a PVR, a much larger proportion of used disk space is going to be temporary usage. I.e. recordings that are saved for a rainy day, watched and then deleted. If fragmentation does ever become an issue, losing all the data by reformatting is not so devestating. Copying the whole file system before reformatting is probably not neccesary, although many people may want to copy a few precious recordings first. Although one would need to be a little tech-savvy to do that, one doesn't need a 320GB EXT3 HDD. A lot of people will have a USB memory stick and ability to use this to temporarily copy a few recordings to a PC. I remain resigned to the possibility that I may have to reformat one day (if the HDR, hopefully, lasts that long) but the prospect does not particularly worry me. I've got a USB memory stick .
|
|
|
|
|
|
#45 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
I don't think there is any need for this facility.
If you can't remember what programmes you have already watched you could create a folder called 'Delete' and transfer any recording you want to delete to that folder by using the file manager. Next time you turn the box on just go to that folder and delete the programmes ![]() The solution you propose is extremely clunky and requires a great many more keypresses than simply tagging a file. |
|
|
|
|
|
#46 |
|
Forum Member
Join Date: Jan 2005
Posts: 69
|
Quote:
Thanks Bob_Cat.
I think I can see where the delete problems are coming from and I don't now expect anything major to change on that front in the upcoming update. The one thing you could do is to allow us to mark files for deletion and then, when the box isn't recording provide a command to delete all tagged files. Not an absolutely perfect resolution but one that would be easy to implement and a big improvement on what we have now. |
|
|
|
|
|
#47 |
|
Forum Member
Join Date: Nov 2008
Location: Co. Donegal
Posts: 797
|
Quote:
This is a great idea. Since the 'new' flag against programs is not visible at the top folder level, it can take a while to go through each folder and hunt down each program for deletion (if you are doing this at a later date when your box is ready and available for deletions). I don't think the file manager work around is really practical in the long run, very clunky, but it's a workaround none the less.
I also find Bob_Cat's concern, that deferred deletion will result in user confusion when the graph doesn't change, somewhat unconvincing. An on-screen message to the effect that the recording will be deleted later would address that. |
|
|
|
|
|
#48 |
|
Forum Member
Join Date: Nov 2004
Posts: 223
|
Quote:
I also find Bob_Cat's concern, that deferred deletion will result in user confusion when the graph doesn't change, somewhat unconvincing. An on-screen message to the effect that the recording will be deleted later would address that.
Simply changing the "delete" option text to "Mark for deletion" and a quick dialogue the first time you do it saying something like "Recordings marked for deletion will be deleted at the earliest opportunity (watching and recording other shows may delay this process)" would suffice. And even that's kind of overkill. |
|
|
|
|
|
#49 |
|
Forum Member
Join Date: Nov 2006
Posts: 107
|
Quote:
Simply changing the "delete" option text to "Mark for deletion" and a quick dialogue the first time you do it saying something like "Recordings marked for deletion will be deleted at the earliest opportunity (watching and recording other shows may delay this process)" would suffice. And even that's kind of overkill.
I'd still like to see some auto deletion options as the current 'stop recording new stuff when the disc is full' doesn't really reflect most use cases - for most people the new programmes are the ones they're most likely to watch and the stuff that's old and unwatched probably never will be. As a minimum there should be a 'delete this programme' pop up when stopping viewing at over c90% of the programme length. |
|
|
|
|
|
#50 |
|
Forum Member
Join Date: Nov 2008
Location: Co. Donegal
Posts: 797
|
When it comes to deleting, there are several other ways in which a deferred delete could be implemented without causing user confusion when the utilisation graph doesn't change.
An obvious one is the use of a "Recycle Bin" which probably most users would already be familiar with. The default action would then be to move recordings to the "Recycle Bin". This would then be emptied automatically during it's nocturnal housekeeping. It could also be emptied by the user using the File Manager when the box is not recording. A refinement would be to also have an "Immediate Delete" option in addition to the standard delete. This would behave like the current delete (although it would be better for it to be greyed out when the box is recording, rather than not present at all). Another refinement would be the ability to recover recordings in the "Recycle Bin" by moving them with File Manager. If such an approach was to be implemented, I would suggest that the Recycle Bin folder not be visible in the Media List but to be visible in the File Manager. Another variation would be very much as above except that, rather than moving the recording to a "Recycle Bin", they remain where they are but have an icon to indicate that they wll be deleted. I think the ""Recycle Bin" approach would be better as people will already be familiar with the concept. There are probably a number of other variants on the same themes. There's certainly sufficient possibilities for Humax not to have any excuse for not providing a more user friendly delete function. They just haven't thought about it hard enough . |
|
|
|
![]() |
| Thread Tools | Search this Thread |
|
All times are GMT. The time now is 23:47.





)

