Improvement request. Media display. Directory contents

grampus · Post by **grampus** » Fri Apr 15, 2016 21:14

Like to suggest an improvement request.

At the moment, I have a number of sub-directories for my series recordings in the movie directory. .

I would like to be able to see an indicator maybe of how many shows are still in the sub directories.

I.E. Hit media on the remote. On mine it goes to the HDD/Media/movie directory
Display shows all the movies under the that directory, and all the directories I have created for each series.
When I get this display up, I have to go enter each sub directory to see what is there.
After a while I have a viewing binge, and go through a series, deleting them as I go.
Until I have none left in a directory. Of course I forget which ones I have gone through, and wouldn't mind an indicator to show what i had left.

At this stage I thought it may be interesting to display something on the right hand window of the display. Doesn't have anything there at this time. But maybe a recording count against each sub directory.
Of course a number of other displays come to mind, but that would be a way of quickly identifying what may be there.

prl · Post by **prl** » Fri Apr 15, 2016 21:48

Can you suggest how that would work efficiently if they are large subfolders on a NAS, or even on the HDD, then? Listing folders in the media player is already too slow.

This has been discussed several times already on the forum.

grampus · Post by **grampus** » Fri Apr 15, 2016 22:02

prl wrote:Can you suggest how that would work efficiently if they are large subfolders on a NAS, or even on the HDD, then? Listing folders in the media player is already too slow.

This has been discussed several times already on the forum.

just a number would just about suit my request. not so much the detail.
maybe in the right window in line with each sub directory just the number of recordings.

prl · Post by **prl** » Fri Apr 15, 2016 22:19

grampus wrote:
prl wrote:Can you suggest how that would work efficiently if they are large subfolders on a NAS, or even on the HDD, then? Listing folders in the media player is already too slow.

This has been discussed several times already on the forum.
just a number would just about suit my request. not so much the detail.
maybe in the right window in line with each sub directory just the number of recordings.

The number was all I was thinking of, and the display of the number is trivial. The only way to get the number is to read the directory name entries for every subdirectory of the current directory. From that there's probably enough information to work out the number of playable entities (which is not equal to the number of files).

But as I said, the directory listing fill is already too slow. I'm not keen on anything that makes it slower.

One alternative would be to do the number of entries on demand when a directory is in focus and display it in the "size" field.

grampus · Post by **grampus** » Fri Apr 15, 2016 22:34

prl wrote: One alternative would be to do the number of entries on demand when a directory is in focus and display it in the "size" field.

certainly don't wish to make it cumbersome.
I'm assuming you mean as you toggle up and down the directory list, just display that directories number of files noted.
I think that would be acceptable to me anyway.

prl · Post by **prl** » Sat Apr 16, 2016 12:03

That's the idea. In the field that currently shows the recording size.

There's another question, too. How are subdirectories to be included in the count? Should the count be just files, files + directories or two separate numbers for files and directories?

peteru · Post by **peteru** » Sat Apr 16, 2016 14:17

Can of worms. How are you going to treat a mount point to a NAS volume that has 30TB of data and a million directories?

grampus · Post by **grampus** » Sat Apr 16, 2016 14:51

ah well, sounded like a good idea at the time for my fairly simplistic operation.

prl · Post by **prl** » Sat Apr 16, 2016 14:56

peteru wrote:Can of worms. How are you going to treat a mount point to a NAS volume that has 30TB of data and a million directories?

I don't mean the whole subtree under a folder. I just mean the direct descendants. I agree that doing a complete subtree total would simply be asking for trouble.

E.g. if /media/hdd/movie has a subdirectory Movie, and it had sub-folders Horror and Action, and recordings "The Three Colours - Red", "The Three Colours - Blue" and "The Three Colours - White", the numbers reported in the media selection list should show Movie as containing two folders and three media items, no matter what's in the folders Horror and Action.

I'm not sure if that's what grampus meant, and I'm still not sure whether even my more limited proposal of only showing the number of items (directly) in the subfolder in focus is a good idea from an implementation point of view. I think it is a good idea from the point of view of user information (is there anything in that folder?), especially for folders whose contents are placed there automatically, either by the timer "location" field or by Series2Folder.

peteru · Post by **peteru** » Sat Apr 16, 2016 15:33

I wonder if it would be possible to derive some heuristics from the stat of a directory to determine the likely "size" of it's contents. The question here is mainly, is there stuff to watch there. To answer this, you could say no/yes or perhaps expand it to no/a bit/ loads.

EDIT: I checked. Not promising on ext4. Empty dir shows as 4096 bytes, but so does a dir with 10+ files that add up to a few hundred GB. A dir that shows as 65536 bytes has 655 files in it.

Still, boiling down the implementation to yes/no could allow you to terminate the directory listing earlier - as soon as you find the first playable file.

I'm still not convinced that this is a useful feature, rather than more bloat. I'd much rather see some kind of content indexing that runs in the background so that queries like this can be done against a database rather than traversing the file system every time you have a question.

grampus · Post by **grampus** » Sat Apr 16, 2016 15:40

like I said, I really only wanted something simple.
my thought was running along the lines of those email displays that show how many unread messages you have.
or just how many in total, no thoughts as to size or number of files involved in each.

seems it's not all that simple a task.
not to worry , I'll just enter each directory and have a Squizzy each time.

prl · Post by **prl** » Sat Apr 16, 2016 16:10

peteru wrote:I wonder if it would be possible to derive some heuristics from the stat of a directory to determine the likely "size" of it's contents. The question here is mainly, is there stuff to watch there. To answer this, you could say no/yes or perhaps expand it to no/a bit/ loads.

EDIT: I checked. Not promising on ext4. Empty dir shows as 4096 bytes, but so does a dir with 10+ files that add up to a few hundred GB. A dir that shows as 65536 bytes has 655 files in it.
...

Only really old native Unix filesystems like the v6 filesystem really allowed you to guess how many entries were in a directory by a stat of the directory. The v6 filesystem had fixed length directory entries of 16 bytes, 14 bytes for name and 2 bytes for inode number. Inode number 0 meant an unallocated entry. Even then the length of a directory may have just reflected the maximum size the directory ever had (I can't recall whether that's right, but v6 didn't have a trunc(2) system call). From at least the BSD 4 Fast File System onwards, directory entries have been variable-length.

Ext4 directories can be either linked lists or a hashed B-tree (format-time? filesystem flag).

MrQuade · Post by **MrQuade** » Sat Apr 16, 2016 19:26

grampus wrote: seems it's not all that simple a task.

The task *is* simple, but the point that everyone is probably not quite making clear here is that it would take the Wiz a *long* time to process and count all those files in subdirectories.

It already takes some time to list the contents of a large directory, and if the Wiz had to dive into every subdirectory to count the files in each one, it would take that much longer to list all the files.

It is a trade off between things that would be great to have, and things that the Wiz has enough power to actually do in a reasonable amount of time.

grampus · Post by **grampus** » Sat Apr 16, 2016 19:46

some of you must have some hellishing big directories. think I'm lucky if I have more than 6 in each. I clean them up after watching generally.

not to worry.
pull back the request if it's that big a deal.

prl · Post by **prl** » Sat Apr 16, 2016 20:03

grampus wrote:some of you must have some hellishing big directories. think I'm lucky if I have more than 6 in each. I clean them up after watching generally.

not to worry.
pull back the request if it's that big a deal.

It's not just your use pattern that matters. It also needs to work for people with large recording or media collections.

It's actually something that I'd find useful myself.

MrQuade · Post by **MrQuade** » Sat Apr 16, 2016 20:07

Yes,, it's a good suggestion, but take into account what prl is suggesting.

It's not so much that people have gigantic recording directories, it's just that when you write software, you have to account for "edge cases", or on other words, the worst case scenario.

The time required to count the files is greatly reduced if you only count the files within the directory that is currently highlighted. In other words, if you don't have to count the files in every subdirectory of the directory, you are in, that time factor problem goes away somewhat.

Prl was asking, if you only count the files in the currently selected subdirectory, do you count the total number of files in that directory, or the number of playable files in that subdirectory.

Also if that subdirectory has its own subdirectories, do you count files that are in them too. PeterU suggested that you could end up counting forever if you started down that line of thought.

Alternately, if the subdirectory points to a network location that is not currently available, you may have to end up waiting for the network to time out before continuing.

Even then, if you had a subdirectory that contained several hundred files, would that end up causing the Wiz to stutter and pause as you scrolled down your directory listing.

Lots of things to consider.

But I guess the basic question is, would you be happy to only see the files for the currently selected directory, or do you want to see the files within all subdirectories at once. The former is probably doable, the latter would probably be a bad idea.

Programming is a battle between the programmer with good intentions and the users who will always find ways to break your creation

grampus · Post by **grampus** » Sat Apr 16, 2016 20:42

I guess I would look at it this way from my perspective.
I don't have massive subdirectories. as in Genres, down to series under those genres.
I just have a number of directories under the basic movie directory, each one is a series directory.
I would really be interested seeing what is in the highlighted directory. as a number of playable shows only.
don't care about the number of files associated with a show, or the size of the files. in my mind it would be just a number only.
e.g. a directory say of new tricks, all I would need to know how many shows I have recorded in that directory.

prl · Post by **prl** » Sat Apr 16, 2016 21:23

Our directory structure is similar, and I would want something like this for similar reasons.

peteru · Post by **peteru** » Sat Apr 16, 2016 21:57

Well, consider my directory structure...

Under movies I have a rage directory that has every screening of rage for the last 6 months. It has just over 3500 entries. I also have about 3500 entries in the movie directory itself and another directory with content from ABCKIDS with around 2000 entries. Then there are about 10 directories for autotimers, each with 300-800 entries each.

Once the cache on the /hdd/movie directory is populated, it still takes 1.25 seconds to do a ls -alR. Python code that performs some logic on the entries is likely to take at least one order of magnitude longer. If the disk cache is not populated, doing the same operations will take several orders of magnitude longer.

This is on a fast 6TB drive with ext4. Network mounted drives will be a lot slower.

I think that this feature has the potential to lead to the same issues we have seen with the resume cache. Namely, slow downs of the user interface for no apparent reason.

I understand the user interface benefits and agree that the additional information would be useful, but before anyone sets down on the path of implementing this feature, it really needs a good design with performance as one of the primary metrics. In a better programming environment, I'd suggest an asynchronous task and a cache, but enigma2 code base does not make that approach practical.

MrQuade · Post by **MrQuade** » Sat Apr 16, 2016 22:02

Might I suggest some optimisations that may help potential performance issues?

Only display files contained in sub-directories, if you are currently viewing "Default movie location", "Timer recording location" or "Instant recording location". That way, you will more than likely not be counting folders that people have stored vast libraries of downloaded media.

Only files within regular directories. Don't count files within symlinks that point to other locations. This would hopefully mitigate scenarios where people have created shortcuts to network locations that may be unavailable, and may contain tons of files.

I would agree that you should only count playable media files located within the subdirectory, but not search recursively into deeper sub-directories.

I have no solution to PeterU's example of several thousand recordings within a subdirectory though

peteru · Post by **peteru** » Sat Apr 16, 2016 22:08

I see MrQuade is trying really hard to skin this feral cat, but really, if you have to have such complex rules for the directory traversal heuristics, you know that your design is less than optimal.

MrQuade · Post by **MrQuade** » Sat Apr 16, 2016 22:25

peteru wrote:I see MrQuade is trying really hard to skin this feral cat, but really, if you have to have such complex rules for the directory traversal heuristics, you know that your design is less than optimal.

Agreed, And even with those suggestions, you end up with a solution that is inconsistent in behaviour and somewhat limited.

It's not really a feature that I had felt much of a need for, but I do like to help people think about the implications of what it is they are asking for

.

kenmax · Post by **kenmax** » Sun Apr 17, 2016 00:00

Would it help if it was an option which could be turned on or off? People with large collections could turn it off, people with normal

collections could turn it on!

peteru · Post by **peteru** » Sun Apr 17, 2016 04:12

No. If it can't be made to work reliably for every scenario, then it doesn't belong in the firmware.

grampus · Post by **grampus** » Sun Apr 17, 2016 08:50

well, for something my tiny brain thought was a simple add function, ended up blowing out a bit.

grampus · Post by **grampus** » Sun Apr 17, 2016 09:14

Just went off piste for a moment there, and had visions of a FACT programmer standing by a console waiting patiently with a bunch of punch cards in hand waiting for a box full of printer paper to roll out of the printer looking for that one vital piece of the puzzle to come into view.
wondering how he would go handling this.

sorry 'bout that.
tends to show my age a bit there methinks.

Grumpy_Geoff · Post by **Grumpy_Geoff** » Sun Apr 17, 2016 12:40

grampus wrote:well, for something my tiny brain thought was a simple add function, ended up blowing out a bit.

Are you using AutoTimers and custom recording locations?
If so, as a 'there's something to watch' indicator, delete the folder once all of the recordings in the folder have been watched.
As the folders recreate with new recordings from those AutoTimer generated timers, you'll know there's something to watch. Watch the contents, and then delete the folder, Rinse, repeat.
Detailed in this post by jazza

prl · Post by **prl** » Sun Apr 17, 2016 13:17

Yes, that works well with folders created by the Location settings in plain timers and AutoTimers.

It doesn't work well with some usage patterns of Series2Folder (in particular, not our usage of it

). We leave progtams that we keep up-to-date with in the main movies folder, and have "Automatically create folders" set to "no autocreate". When we want to activate Series2Folder for a series, we just run "Sel[ected] Series to Folder" on a recording from the series, and that puts all the existing recordings of that series into a folder, and thereafter, the existence of the folder serves as the flag to SeriesToFolder that recordings of the series should be moved to the folder.

I've had pretty much the same discussion as this with a SeriesToFolder user (MrQuade?) about just this issue of knowing when SeriesToFolder had put something into a folder ready for viewing.

There are other usage patterns for SeriesToFolder that will work with using the existence of the series folder as a flag that there's something in it.

kenmax · Post by **kenmax** » Sun Apr 17, 2016 13:52

peteru wrote:No. If it can't be made to work reliably for every scenario, then it doesn't belong in the firmware.

I was thinking along the lines of reliable, but this does not necessarily mean quickly, hence the option to turn off if it is reliable but slow.
But just a thought, I am not that fussed myself!

grampus · Post by **grampus** » Sun Apr 17, 2016 14:20

Grumpy_Geoff wrote:
grampus wrote:well, for something my tiny brain thought was a simple add function, ended up blowing out a bit.

Are you using AutoTimers and custom recording locations?
If so, as a 'there's something to watch' indicator, delete the folder once all of the recordings in the folder have been watched.
As the folders recreate with new recordings from those AutoTimer generated timers, you'll know there's something to watch. Watch the contents, and then delete the folder, Rinse, repeat.
Detailed in this post by jazza

thanks, hadn't seen that one.

peteru · Post by **peteru** » Sun Apr 17, 2016 22:47

Maybe SeriesToFolder needs to shortcut the problem and instead of allowing the recordings to be created in the wrong location, it should just modify the timers to put the recordings in the right location in the first place. From what I see, the main motivation for SeriesToFolder is the fact that IceTV timers always go in the default location.

prl · Post by **prl** » Sun Apr 17, 2016 22:59

peteru wrote:Maybe SeriesToFolder needs to shortcut the problem and instead of allowing the recordings to be created in the wrong location, it should just modify the timers to put the recordings in the right location in the first place. From what I see, the main motivation for SeriesToFolder is the fact that IceTV timers always go in the default location.

That would be a more attractive proposition if IceTV timers didn't get re-created with the default location each time they're updated from the server.

peteru · Post by **peteru** » Sun Apr 17, 2016 23:12

I guess the plugin just needs to be more persistent.

simoncasey · Post by **simoncasey** » Mon Apr 18, 2016 09:20

peteru wrote:Maybe SeriesToFolder needs to shortcut the problem and instead of allowing the recordings to be created in the wrong location, it should just modify the timers to put the recordings in the right location in the first place. From what I see, the main motivation for SeriesToFolder is the fact that IceTV timers always go in the default location.

It's not just an issue with icetv - although that is probably the biggest issue. With autotimers, although you can specify the recording location, if you want recordings grouped by program title you have to create the directory first before you can select it as a location. As such, when I used autotimers for a while I still found it easier to use series2fokder to tidy them up rather than creating all of the folders, selecting the folder in each autotimer and then deleting the folder again to let it get created automatically. Series2foldwr just sorts it out for you after so you don't need to bother.

But I'm not sure that is relevant to the request from grampas as the issue of knowing if there is anything unwatched in a folder is there irrespective of what method was used to record.
I use the watch and delete process for my stuff and the reappearance of a folder indicates a new recording but the wife and kids like to keep some programs. It's not unusual for them to look in an old folder and to find that a new series is being recorded and a few weeks' episodes have appeared unannounced.

Showing a count of the folder contents appears to be hard and doesn't tell you if there is anything new unless the folder was previously empty or you knew how many recordings were already in there.

If this is to be really useful and worth adding to the firmware, I think it needs to have some form of new recording notification - in an ideal world that could be the folder icon in the list view or something that shows the date of the newest recording in a folder when you select the folder.

That doesn't sound easy and it doesn't sound like any of the other options will be that easy to implement without impacting performance and I'm not sure that the other options really solve the need behind the original request.

prl · Post by **prl** » Mon Apr 18, 2016 10:00

peteru wrote:I guess the plugin just needs to be more persistent.

You may have lost sight of why I would find directory contents counts useful: the process I use depends on the existence of a series folder as part of the decision about whether a recording gets put into a folder or not. I don't want all series put into folders.

It doesn't matter whether the mechanism is to move the recordings after they are made or manipulate the location entry in timers, the decision about whether the recording goes into a directory depends on whether the directory exists, so deleting the directory to flag that it's empty disrupts this process.

grampus · Post by **grampus** » Mon Apr 18, 2016 10:02

getting bigger than the binary add that I thought would be the go.

ah me well out of date I am.

prl · Post by **prl** » Mon Apr 18, 2016 10:06

simoncasey wrote:...
If this is to be really useful and worth adding to the firmware, I think it needs to have some form of new recording notification - in an ideal world that could be the folder icon in the list view or something that shows the date of the newest recording in a folder when you select the folder.

That doesn't sound easy and it doesn't sound like any of the other options will be that easy to implement without impacting performance and I'm not sure that the other options really solve the need behind the original request.

The process is the same complexity as counting files and folders.

for files and folder counts:
iterate the names in the folder using readdir(), for each file call stat() to see whether it's a file or folder, and then count files and folders separately (the files probably after testing extensions to see whether they're playable).

for newest recording:
iterate the names in the folder using readdir(), for each file call stat() to see whether it's a file or folder, and if it's a folder check to see whether it's newer than anything encountered so far, and if it is, remember it.

A possibly useful proxy would be the most recently modified timestamp on the folder, but that changes with deletions and moves as well as with new files.

prl · Post by **prl** » Mon Apr 18, 2016 10:06

grampus wrote:getting bigger than the binary add that I thought would be the go.

ah me well out of date I am.

The addition is easy. It's the knowing what to add that can be resource-hungry.

simoncasey · Post by **simoncasey** » Mon Apr 18, 2016 10:14

prl wrote:
simoncasey wrote:...
If this is to be really useful and worth adding to the firmware, I think it needs to have some form of new recording notification - in an ideal world that could be the folder icon in the list view or something that shows the date of the newest recording in a folder when you select the folder.

That doesn't sound easy and it doesn't sound like any of the other options will be that easy to implement without impacting performance and I'm not sure that the other options really solve the need behind the original request.
The process is the same complexity as counting files and folders.

for files and folder counts:
iterate the names in the folder using readdir(), for each file call stat() to see whether it's a file or folder, and then count files and folders separately (the files probably after testing extensions to see whether they're playable).

for newest recording:
iterate the names in the folder using readdir(), for each file call stat() to see whether it's a file or folder, and if it's a folder check to see whether it's newer than anything encountered so far, and if it is, remember it.

A possibly useful proxy would be the most recently modified timestamp on the folder, but that changes with deletions and moves as well as with new files.

I guessed that it would take a similar amount of effort, but I think the date of the most recent recording gives a better indication of whether there is a new recording rather than a count.

I agree that the time stamp doesn't really work as It gets affected by other things.

simoncasey · Post by **simoncasey** » Mon Apr 18, 2016 10:18

prl wrote:
peteru wrote:I guess the plugin just needs to be more persistent.
You may have lost sight of why I would find directory contents counts useful: the process I use depends on the existence of a series folder as part of the decision about whether a recording gets put into a folder or not. I don't want all series put into folders.

It doesn't matter whether the mechanism is to move the recordings after they are made or manipulate the location entry in timers, the decision about whether the recording goes into a directory depends on whether the directory exists, so deleting the directory to flag that it's empty disrupts this process.

I built a hack into my version of the series2folder to get around the deleting folder issue. When series2foldwr creates a folder it also creates a blank file with the same name as that folder and with a dummy extension. When series2folder runs to see if a folder already exists it also checks to see if there is a dummy file and then recreates the folder. That way, even if you delete a folder it will get automatically recreated even if there is just one new recording.

prl · Post by **prl** » Mon Apr 18, 2016 10:45

That sounds useful, but how would a user stop the automatic creation if they wanted to?

simoncasey · Post by **simoncasey** » Mon Apr 18, 2016 11:12

prl wrote:That sounds useful, but how would a user stop the automatic creation if they wanted to?

No easy way with my current hack (without connecting remotely and deleting the file) but it only exists if you have already created the the folder in the first place.

I suppose there could be an option that would allow you to select a folder that had been created and choose Do not auto create. That would create a different flag file that would always be excluded from the create process and would never create a series folder even if you had multiple recordings.

prl · Post by **prl** » Mon Apr 18, 2016 12:02

simoncasey wrote:... I suppose there could be an option that would allow you to select a folder that had been created and choose Do not auto create. That would create a different flag file that would always be excluded from the create process and would never create a series folder even if you had multiple recordings.

The plugin's menu and button entries are not accessible if the media browser's focus is on a directory. This is a general rule for WHERE_MOVIELIST plugins (ones that are inserted into the media browser's menu).

It's not a design choice I entirely agree with, but changing it could easily break WHERE_MOVIELIST plugins. I'm pretty sure doing it would break Series2Plugin/Sel Series to Folder as it is currently implemented.

simoncasey · Post by **simoncasey** » Mon Apr 18, 2016 13:37

In that case it would have to be done by selecting the recording in the folder and creating an exclude flag file in the folder above. Starting to sound a bit over complicated.

peteru · Post by **peteru** » Tue Apr 19, 2016 01:02

prl wrote:the process I use depends on the existence of a series folder as part of the decision about whether a recording gets put into a folder or not. I don't want all series put into folders.

It doesn't matter whether the mechanism is to move the recordings after they are made or manipulate the location entry in timers, the decision about whether the recording goes into a directory depends on whether the directory exists, so deleting the directory to flag that it's empty disrupts this process.

My thinking was that for IceTV, you could have a map of series_id to a directory name. If there is an entry, ensure that the recording location is set. I guess that kind of functionality would probably be best added to the IceTV plugin, rather than series2folder

prl · Post by **prl** » Wed Apr 20, 2016 18:22

peteru wrote:
prl wrote:the process I use depends on the existence of a series folder as part of the decision about whether a recording gets put into a folder or not. I don't want all series put into folders.

It doesn't matter whether the mechanism is to move the recordings after they are made or manipulate the location entry in timers, the decision about whether the recording goes into a directory depends on whether the directory exists, so deleting the directory to flag that it's empty disrupts this process.
My thinking was that for IceTV, you could have a map of series_id to a directory name. If there is an entry, ensure that the recording location is set. I guess that kind of functionality would probably be best added to the IceTV plugin, rather than series2folder

IMO, it would be best done right through from the server->protocol->plugin, but I rather expect that won't happen.

But otherwise, yes, in the plugin would be good.

rrroonn · Post by **rrroonn** » Mon Jul 04, 2016 17:21

Hi all,

Not trying to just throw fuel on the fire, but I think this feature (together with series2folder) is something that really should just be standard behaviour. It certainly is on other PVRs I have used like Windows MCE and MythTV.

Personally, I would consider having two save locations: (1) for timer recordings, and (2) for time-shift buffers.
I would only show folder counts for Location (1), EG

ABC News (3)
Masterchef (4)
etc

I would *only* "count" .ts files in Location (1) and there are approaches that can make this responsive:

Create a background thread that counts folder .ts files and updates displayed listing as it goes
Do counting in foreground thread after showing folder listing and update listing as it goes but would obviously need to poll user-input periodically to remain responsive

You could also limit the counting to only the currently displayed folders (ignore those not currently on screen).

If you wanted to be fancy, you could show unwatched files only, or unwatched / total (EG 2/5).

Personally, I think that series2folder should almost be a feature that has no UI controls (other than maybe some settings). In my view, any recording that was created as a result of an AutoTimer should always be put into a series folder under Location (1). I would create the series folder when the autotimer is created, rename it when the autotimer is renamed, and delete it (if it is empty) when the autotimer is deleted.

I would also get rid of the "custom location" settings and have the recordings just go to the folder mentioned above. There is an argument to be made to simplify the UI though it means less customisation ability. Sometimes simpler is just better.

I understand that the underlying code-base was aimed at being a really flexible recording platform and that these suggestions might be sensible but pretty hard to implement without breaking a lot of things.

Just my thoughts.

Thanks,

Ron

prl · Post by **prl** » Mon Jul 04, 2016 18:38

rrroonn wrote:Hi all,

Not trying to just throw fuel on the fire, but I think this feature (together with series2folder) is something that really should just be standard behaviour. It certainly is on other PVRs I have used like Windows MCE and MythTV.

Have you read the discussion in this topic about why it's difficult to implement this so that it works efficiently in all environments? Also, PCs have a good deal more grunt that the T series, and things that are quick on a PC may not be so fast on a Beyonwiz.

rrroonn wrote:Personally, I would consider having two save locations: (1) for timer recordings, and (2) for time-shift buffers.

It's already possible to specify the location for timer recordings, instant recordings and the timeshift buffer. But people save media and recordings all over the place.

rrroonn wrote:I would only show folder counts for Location (1), EG

ABC News (3)
Masterchef (4)
etc

Nothing displays when you look at the timeshift buffer directory using the media browser anyway, and it doesn't normally have any subdirectories. I'm not really sure what you mean by it only displaying directory contents counts in the recording directory.

Do you really want to count subdirectory counts in only the recordings directory? What if I have <Recordings directory>/Movies/{Drama,Thriller,Comedy,Horror}, etc? If I'm in <Recordings directory>/Movies shouldn't I see the counts for its subfolders?

rrroonn wrote:I would *only* "count" .ts files in Location (1) and there are approaches that can make this responsive:

Create a background thread that counts folder .ts files and updates displayed listing as it goes

Do counting in foreground thread after showing folder listing and update listing as it goes but would obviously need to poll user-input periodically to remain responsive

If all you want to do is count by looking at extensions, that's reasonably fast. But I don't see why you'd only count '.ts' extensions. However, file handing in the media browser probably doesn't work the way you assume it does, and while it may be possible to "bolt on" something similar to what you suggest, there may be contexts where that's not appropriate.

However, some people have very large collections (e.g. see here), and even relatively fast searches may get a bit slow.

rrroonn wrote:You could also limit the counting to only the currently displayed folders (ignore those not currently on screen).

That would be possible, but it would make access a bit uneven because most of the commonly-used sort orders group directories together, so if you paged up into a screen with a lot of big directories, the count could take a while.

rrroonn wrote:If you wanted to be fancy, you could show unwatched files only, or unwatched / total (EG 2/5).

That requires an attempted file open for every entry, and a read of the (short) file for every recording.

In general, you seem to be thinking of the T series as only a PVR. A lot of people use it just as much, or even more, as a media player.

rrroonn wrote:Personally, I think that series2folder should almost be a feature that has no UI controls (other than maybe some settings).

The settings in series2folder allow it to be used in different ways for people with different needs of the plugin. Its original form (written by BikeMike) had no options. The options that are there now were added for what I think are good reasons.

I have a longer-term intention of making it available as a standard downloadable plugin, but it's not currently a high priority.

rrroonn wrote:In my view, any recording that was created as a result of an AutoTimer should always be put into a series folder under Location (1). I would create the series folder when the autotimer is created, rename it when the autotimer is renamed, and delete it (if it is empty) when the autotimer is deleted.

Series2Folder was not primarily intended for use with AutoTimers, though I know some people do use it with that way. Its main intended use was in conjunction with IceTV recordings, which have no mechanism for setting a destination folder.

rrroonn wrote:I would also get rid of the "custom location" settings and have the recordings just go to the folder mentioned above. There is an argument to be made to simplify the UI though it means less customisation ability. Sometimes simpler is just better.

The custom locations settings are a grand total of 4 settings. I don't think that they contribute much to the settings complexity. I think that poor settings descriptions and unexpected setting interactions are more of a problem.

rrroonn wrote:I understand that the underlying code-base was aimed at being a really flexible recording platform and that these suggestions might be sensible but pretty hard to implement without breaking a lot of things. ...

The UI code is open source. Anyone can contribute to improving it.

rrroonn · Post by **rrroonn** » Tue Jul 05, 2016 09:25

Thanks for the detailed response. Yes, I read the whole thread before posting. My suggestions was aimed at making the Beyonwiz more usable and more appealing to a wider audience.

The clear message I get from your response is that the feature request will not be implemented, so I won't follow up any further.

Personally, I can put up with things the way they are.

I may think about contributing in some fashion, where is the source?

thanks,

Ron

About the Forum

Join us