[ViX_Misc] Display Directory Size

[birdman]

A bit of caching would help, as would a delayed render of the size.

Linux caches directory readings itself.

 

[simonc]

Linux caches directory readings itself.

Yes, and despite this, it still takes 400ms to scan my movie directory. Python still has to walk the directory tree, doing an lstat on every one of the 6000 files, so even though lstat is fast for a single call, call it enough times and you've got a problem. It's the total that'd be cached.

 

[birdman]

Yes, and despite this, it still takes 400ms to scan my movie directory. Python still has to walk the directory tree, doing an lstat on every one of the 6000 files, so even though lstat is fast for a single call, call it enough times and you've got a problem. It's the total that'd be cached.

And less than half a second is a long time?
At what pace do you live your life?

 

[simonc]

It's not about getting places quickly or having a hectic life. It's about user experience. Have a think about the implications of waiting half a second before the UI responds every time you highlight a large directory, or one that's on a slow network and might take 20 seconds or more (see twol's earlier post). Even if you're not interested in the size of the directory, it's still going to kick off a scan of the subdirectories and while that's going on you can't do anything while you're waiting. It becomes a barrier to getting to the items you're interested in and you'll probably press the arrow buttons a few times while you're waiting wondering what's going on, which will exacerbate the problem by kicking off more directory scans.

I'm not going to introduce a feature that's there for occasional file management at the expense of making something we use extensively every day less usable.

 

[alphacabbage1]

I see simonc beat me to it - no surprise - but I'll post anyway...

And less than half a second is a long time?
At what pace do you live your life?

"c" speed, I expect and according to Einstein that's quite fast. However, I'm slow on most fronts but I feel the pain with a 5TB disk. It's a psychological hit rather than need -- the seamless interactive flow versus a clunky wait, control v. powerlessness, UX v. system... [insert Design Thinking words]

 

[simonc]

Yes, if this was some kind of on demand feature where you press a button and it displays a size, even taking 20-30 seconds wouldn't be an issue because you've explicitly asked for it to tot up the size. You'd also give some kind of feedback that shows it's having a bit of a think: popping up a please wait message with a way to cancel the operation if it's something that might take even longer.

For browsing within a screen, you want things to feel seamless and fluid, which means working within a 100ms response time ideally, anything longer and we notice the delay and it feels sluggish and unpleasant to use.

 

[ccs]

Something like this, perhaps?

Maybe "info" is a reasonable compromise when selecting a directory or collection? It does nothing at the moment.

 

[simonc]

Sorry, yes I saw that yesterday and should've mentioned that not everyone has an info button!

 

[ccs]

Sorry, yes I saw that yesterday and should've mentioned that not everyone has an info button!

I manage to cope. Maybe the blue button, or something else.

tbh, I'm not bothered about directory sizes, programme lengths gives me a good enough clue, and when you're in a folder/collection you can see individual programme sizes.

(Not sure if those sizes are getting rounded up/down to the nearest Gigabyte? Megabytes look ok/more accurate.)

 

[simonc]

I've been experimenting this weekend and found that you can just about get away with making the user wait for the size calculation on a local disk without it being a glitchy experience given the right conditions:

• The OS needs to have already cached the file sizes
• You need to avoid hitting a directory with more than a thousand files, e.g. I have a music directory containing 5000+ files which takes 1 second to calculate (once the OS caching has happened).
• Anything that's on a network has potential to be slow or take time to fail if the network is down

With this in mind calculating in the background seemed a better choice. If it's taking ages to calculate, you can bail out and scroll past without glitches. The size is displayed in the same location as recording sizes. I've also enabled sizes to be displayed for collections.

 

[BrokenUnusableAccount]

It's not about getting places quickly or having a hectic life. It's about user experience. Have a think about the implications of waiting half a second before the UI responds every time you highlight a large directory, or one that's on a slow network and might take 20 seconds or more (see twol's earlier post). Even if you're not interested in the size of the directory, it's still going to kick off a scan of the subdirectories and while that's going on you can't do anything while you're waiting. It becomes a barrier to getting to the items you're interested in and you'll probably press the arrow buttons a few times while you're waiting wondering what's going on, which will exacerbate the problem by kicking off more directory scans.

In an ideal implementation you wouldn't have to wait for it to scan and add up the sizes unless you wanted to, you would be able to moving the cursor around without waiting if you chose and the scanning would be interrupted before it completed.

But I am saying this with no real idea of how difficult this would be to do in the OpenViX UI.

 

[birdman]

You could the count of directories and total size (block count?) of files in each location, along with the percentage of that filesystem in use (or free).
That should be quick for all instances. But might be no more useful than the current display.

 

[simonc]

Which is bang on what we're getting :thumbsup:

 

[ccs]

While you're on a roll, any chance of adding the programme description (of the earliest recording?) when highlighting a collection?

 

[simonc]

Ha, I vaguely remembered your request from March and started having a look yesterday. One question: should it actually show the description of the item that's bottom or maybe top of your chosen sort order?

 

[ccs]

Ha, I vaguely remembered your request from March and started having a look yesterday. One question: should it actually show the description of the item that's bottom or maybe top of your chosen sort order?

My sort order is always the default "by date" so my preference would be the bottom of that list.

I'd rather see the first episode description (the oldest) rather than the last episode (which is at the top), as it might contain spoilers.

 

[Joe_90]

Maybe the collection entry could also show the date of the oldest recording in the list? It currently shows 1st Jan 1970.

 

[simonc]

Maybe the collection entry could also show the date of the oldest recording in the list? It currently shows 1st Jan 1970.

Ah, yes. Not spotted that because my skin doesn't display that info.

Agreed that showing the oldest episode description is the safest in all cases.

 

[simonc]

Now that I look again, when selected, directories show 1st Jan 1970 as well. Lets keep things simple and not show a date for those or for collections.

I experimented with making the selecting of a collection show all the details (start time, durection, picon) of the oldest recording, but it was starting to get a bit misleading: it looked like you'd selected a recording. I'll stick with just the description and the total size of the collection.

 

[ccs]

Ah, yes. Not spotted that because my skin doesn't display that info.

Agreed that showing the oldest episode description is the safest in all cases.

Thanks for adding the feature, looking good in 5.5.014.008 :thumbsup: