View Full Version : [ViX_Misc] Display Directory Size
I've looked in the "0 Help Menu Info" items and then Movie List Setup and can't find anything to select display directory size.
Any chance that the directory size in Play list could be included in a future software version??
So bottom right which is:
"Directory xxGB (yy%) free diskspace"
could read:
"Directory zzG/MB xxGB (yy%) free diskspace"
And I can't find a Help button on the Gigablue V2 handset and wonder if there is one.
I also note "Enable automatic collections"? Is that a new option and does it do similar to tags or movieorganisor?
I also note "Enable automatic collections"? Is that a new option and does it do similar to tags or movieorganisor?
It seems to create 'virtual' directories for series recordings.
I record to a NAS and if I enable it one machine then everything appears to be in separate folders but not on any other box if that makes sense?
Thanks. I'll try and see what happens.
I also note "Enable automatic collections"? Is that a new option and does it do similar to tags or movieorganisor?
I've been using it for ages, it alters how recordings are displayed, but doesn't change the actual files/folders, so when you switch it off you're back to where you were.
Help may be on F1.
I don't understand the directory question.
Sorry got port and starboard crossed.
In the bottom left corner of the Playlist screen is a display of freespace of hard drive: -
"Directory xxGB (yy%) free diskspace"
It would be really useful to amend the read out in the bottom left corner to include the size of the directory in that read out: -
"Directory zzG/MB xxGB (yy%) free diskspace"
Hope that is clear.
Ok, but it is not a directory. That percentage is the total space on the drive minus the total used.
I think that it is about this : the size of the selected directory is missing
62389
I think that it is about this : the size of the selected directory is missing
62389What directory? Directories don't have sizes. They increase automatically to accommodate the contents. The free space listed is the free space on the mount.
spanner123
16-07-21, 07:31
What directory? Directories don't have sizes. They increase automatically to accommodate the contents. The free space listed is the free space on the mount.
I think he means showing the size of the folder when you select it.
I think he means showing the size of the folder when you select it.
I think he really means the total size of all the files in the folder.
spanner123
16-07-21, 09:34
I think he really means the total size of all the files in the folder.
That's what I thought I said lol. The folder will have no size on its own.
BrokenUnusableAccount
16-07-21, 20:04
It would be a nice feature if one could always immediately see the total space used by the files in a folder or collection just by placing the cursor on it.
This is a good idea, but a tricky one, which is probably why we don't have it already. It'd have to be fairly carefully implemented to prevent slowness whilst scrolling past a directory of no interest, especially as the default is to scroll past all your directories before you get to recordings. If you remember to use left and right to page, it isn't quite as bad, but not everyone remembers to use these.
This is a good idea, but a tricky one, which is probably why we don't have it already. It'd have to be fairly carefully implemented to prevent slowness whilst scrolling past a directory of no interest, especially as the default is to scroll past all your directories before you get to recordings. If you remember to use left and right to page, it isn't quite as bad, but not everyone remembers to use these.
Maybe "info" is a reasonable compromise when selecting a directory or collection? It does nothing at the moment.
Probably something as simple as a pause before starting to work out the size of the directory, which gives time to scroll past before things lock up. There are some complications though:
1. The filling of file sizes is done using data binding from the skin, so it's not very controllable
2. Python directory walks are slow :(
There might be some interesting things we can do now that we've got Python 3 features available to us.
Probably something as simple as a pause before starting to work out the size of the directory, which gives time to scroll past before things lock up. There are some complications though:
1. The filling of file sizes is done using data binding from the skin, so it's not very controllable
2. Python directory walks are slow :(
There might be some interesting things we can do now that we've got Python 3 features available to us.
Python walks are not just slow -I ripped a few out of the code when testing because at one point it took over 10 minutes to boot up after an image flash (I did have a couple of HDD‘s attached as I was testing the Harddisk code)
If you remember to use left and right to page, it isn't quite as bad, but not everyone remembers to use these.Or just use Up at the top, which takes you to the bottom....
2. Python directory walks are slow :(But a recursive lstat() of all entries under a directory shouldn't be - you're just reading the inode info.
os.walk is a poor performer on Python 2. Python 3 improves it, and has also got os.scandir, which is 50-75% quicker. Some figures for my TV directory (6000~ files, ignoring the initial load measurement when it's scanning the actual disk)
os.scandir: 88ms
os.scandir+os.lstat: 411ms
and for a slightly more realistic subdirectory of 600 files (120 recordings)
os.scandir: 10ms
os.scandir+os.lstat: 44ms
So, it'll be a sluggish browsing experience if you have very big directories, or if you ever browse an entire drive
A bit of caching would help, as would a delayed render of the size.
A bit of caching would help, as would a delayed render of the size.Linux caches directory readings itself.
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.
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?
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
19-07-21, 14:54
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]
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.
Something like this, perhaps? :)
Maybe "info" is a reasonable compromise when selecting a directory or collection? It does nothing at the moment.
Sorry, yes I saw that yesterday and should've mentioned that not everyone has an info button!
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.)
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
26-07-21, 00:48
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.
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.
Which is bang on what we're getting :thumbsup:
While you're on a roll, any chance of adding the programme description (of the earliest recording?) when highlighting a collection?
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?
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.
Maybe the collection entry could also show the date of the oldest recording in the list? It currently shows 1st Jan 1970.
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.
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.
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:
Thanks for adding the feature, looking good in 5.5.014.008 :thumbsup:
Not sure how (MS Edge), but the g's in looking good have both lost the tail in my last post. Just quoting to see what happens.
EDIT: looks ok in the quote. :confused:
Changing the magnification up or down from 100% brings the tail back.
Post #33 does the same, the rest on this page are ok.
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.
Thanks for that in 5.5 builds. Is it being ported to 5.4 or is it py3 only? I don't see any recent commits for directory/collections in the Dev branch.
I think it is about time that we switch to the Py3 compatible branch for all builds.
Yes, this feature wouldn't work on Python 2; I used one of the new, faster, Python 3 directory scanning functions.
Yes, this feature wouldn't work on Python 2; I used one of the new, faster, Python 3 directory scanning functions.
Does that mean we now have code in that branch that is not compatible with Py2? The plan was that branch would run on both so we could use it for both builds until we drop Py2 altogether.
We can put a version check in and use the slower API under py2 if needed.
Yes. If you could please. Anyway if it is run in a thread it shouldn't matter about time.
BTW, I'm not sure if it is relevant but, there is a Py2/3 threading example in Satfinder.
https://github.com/OpenViX/enigma2/blob/Dev-python3-compatible/lib/python/Plugins/SystemPlugins/Satfinder/plugin.py#L36-L39
alexwilmac
17-08-21, 08:25
The folder's size and the number of files within it is a feature of EMC (Enhanced Movie Center) which also allows to select multiple file and then play them sequentially.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.