directory structure

[jake.t]

hi Everyone,

does anyone know if there's a way to control the directory structures to create nested searches?

what I mean is, for instance from the main folders, select Year_added, under that select Month_added, under that select Day_added?

it makes no sense selecting a month across years, or a day for that matter.

[simoncn]

(10-09-2014 00:12)jake.t Wrote:  hi Everyone,

does anyone know if there's a way to control the directory structures to create nested searches?

what I mean is, for instance from the main folders, select Year_added, under that select Month_added, under that select Day_added?

it makes no sense selecting a month across years, or a day for that matter.

MinimServer is designed to allow you to browse for any tags at any time. There isn't a way to disable some tag choices until other tag choices have already been made.

[DavidHB]

(10-09-2014 00:12)jake.t Wrote:  does anyone know if there's a way to control the directory structures to create nested searches?

what I mean is, for instance from the main folders, select Year_added, under that select Month_added, under that select Day_added?

it makes no sense selecting a month across years, or a day for that matter.

This is an awkward query to respond to, because it is not immediately clear what you are trying to do, or what, in this context, you mean by "Directory Structure".

The normal MinimServer dynamic browse tree is not constructed from folder locations but from tags in the music files, via an index. In many control points, nodes in the tree are represented as folders, so this may be what you are referring to. Simon's advice in the preceding post is relevant here; the whole point of a dynamic browse tree is that it makes the selections as you browse, rather than defining the tree in advance, as is done in other server programs. You change the behaviour of the browse tree by defining (in Settings) which tags are indexed and of course through the content of the tags themselves. As there is a Date tag, it is certainly possible to browse items by Date, though that is typically a publication date, rather than a date added. It might be possible to add special tags to do what you have in mind.

MinimServer also offers [folder view] which allows you to browse the folders in the music directory as if you were in a file manager. In that case, the folders are whatever you have set them to be in your ripping program or using your file manager or whatever. MinimServer simply deals with the folder structure that it finds, so arranging the folders to suit your needs is a file management task.

This isn't much help, I fear. If you can give an example of precisely what you wish to do, it might be possible to offer more specific advice.

David

[jake.t]

(10-09-2014 11:09)DavidHB Wrote:  

(10-09-2014 00:12)jake.t Wrote:  does anyone know if there's a way to control the directory structures to create nested searches?

what I mean is, for instance from the main folders, select Year_added, under that select Month_added, under that select Day_added?

it makes no sense selecting a month across years, or a day for that matter.

This is an awkward query to respond to, because it is not immediately clear what you are trying to do, or what, in this context, you mean by "Directory Structure".

The normal MinimServer dynamic browse tree is not constructed from folder locations but from tags in the music files, via an index. In many control points, nodes in the tree are represented as folders, so this may be what you are referring to. Simon's advice in the preceding post is relevant here; the whole point of a dynamic browse tree is that it makes the selections as you browse, rather than defining the tree in advance, as is done in other server programs. You change the behaviour of the browse tree by defining (in Settings) which tags are indexed and of course through the content of the tags themselves. As there is a Date tag, it is certainly possible to browse items by Date, though that is typically a publication date, rather than a date added. It might be possible to add special tags to do what you have in mind.

MinimServer also offers [folder view] which allows you to browse the folders in the music directory as if you were in a file manager. In that case, the folders are whatever you have set them to be in your ripping program or using your file manager or whatever. MinimServer simply deals with the folder structure that it finds, so arranging the folders to suit your needs is a file management task.

This isn't much help, I fear. If you can give an example of precisely what you wish to do, it might be possible to offer more specific advice.

David

thanks David, it totally makes sense the way its done and normally for situations like composer, conductor, Orchestra is feasible that once you've chosen a composer, you want to select a conductor, and perhaps an Orchestra.

What I've done and find very useful is use the %file_create_date% to breakout the year, month and day the material was added to the collection.

this allows me to quickly go through the collection and listen to 'new' material at any time.

from the root, selecting a month or a day doesn't make much sense because they are arbitrary without a year so I want to nest the month index within the Year index, and day within the Month.

does that make sense?

[DavidHB]

Sorry not to come back sooner; I've not had much keyboard time available recently.

(10-09-2014 13:50)jake.t Wrote:  from the root, selecting a month or a day doesn't make much sense because they are arbitrary without a year so I want to nest the month index within the Year index, and day within the Month.

does that make sense?

Yes it does, as a concept. I didn't quite get your reference to %file_create_date%, though it would make sense if it was a reference to something you are doing in MP3Tag.

Let us assume that you have a create_date tag in your files, derived from the original file creation date and therefore equivalent to the accession date of your file in your library. If you were to put, say, "-create_date" (index by accession date in descending order) in your indexTags property, this would order file creation dates with the most recent entries at the top. Likewise, in your TagOptions property, you could use the create_date tag in the Album.sortTag entry. This would pretty readily enable you to identify the most recent items in the current selection.

In the normal intelligent browsing fashion, if the items in the current selection (for example of a particular artist) have different accession dates - as they would have - there will be a create_date option in the browse tree at that point, with the most recent items at the top of the date list when you select it.

If you wish to go further than this, things start to get complicated. It is theoretically possible to have separate create_year, create_month and create_day tags, and add them (descending) to indexTags. This would, at least conceptually, allow you to use the browse tree to select, say, the year and then the month. It seems to me to be a lot of work for not much gain, but you might think differently. Personally, if I were implementing date-based indexing, I'd be inclined to stick with a single date for the accession field, and use the browse tree to filter entries before selecting a date-based list.

[Edit] Of course, all this assumes that you structure your date tags in such a way that they will sort correctly, as in "2004-10-21" or whatever.

I hope these thoughts help.

David

[jake.t]

(11-09-2014 12:12)DavidHB Wrote:  Sorry not to come back sooner; I've not had much keyboard time available recently.

(10-09-2014 13:50)jake.t Wrote:  from the root, selecting a month or a day doesn't make much sense because they are arbitrary without a year so I want to nest the month index within the Year index, and day within the Month.

does that make sense?

Yes it does, as a concept. I didn't quite get your reference to %file_create_date%, though it would make sense if it was a reference to something you are doing in MP3Tag.

Let us assume that you have a create_date tag in your files, derived from the original file creation date and therefore equivalent to the accession date of your file in your library. If you were to put, say, "-create_date" (index by accession date in descending order) in your indexTags property, this would order file creation dates with the most recent entries at the top. Likewise, in your TagOptions property, you could use the create_date tag in the Album.sortTag entry. This would pretty readily enable you to identify the most recent items in the current selection.

In the normal intelligent browsing fashion, if the items in the current selection (for example of a particular artist) have different accession dates - as they would have - there will be a create_date option in the browse tree at that point, with the most recent items at the top of the date list when you select it.

If you wish to go further than this, things start to get complicated. It is theoretically possible to have separate create_year, create_month and create_day tags, and add them (descending) to indexTags. This would, at least conceptually, allow you to use the browse tree to select, say, the year and then the month. It seems to me to be a lot of work for not much gain, but you might think differently. Personally, if I were implementing date-based indexing, I'd be inclined to stick with a single date for the accession field, and use the browse tree to filter entries before selecting a date-based list.

[Edit] Of course, all this assumes that you structure your date tags in such a way that they will sort correctly, as in "2004-10-21" or whatever.

I hope these thoughts help.

David

Thanks David, that works for me!

the mp3tag reference is correct, %file_create_date% is an informational tag I can pull. Although it its raw form it is listed with Month first I can reformat the output to the new created tag as I wish to manipulate things a little to come out how I want.

thanks for you help!

[DavidHB]

(12-09-2014 12:57)jake.t Wrote:  the mp3tag reference is correct, %file_create_date% is an informational tag I can pull. Although it its raw form it is listed with Month first I can reformat the output to the new created tag as I wish to manipulate things a little to come out how I want.

This is where the capability of MP3Tag to search and replace using Regular Expressions (if you can get your head round them!) really comes into its own.

(12-09-2014 12:57)jake.t Wrote:  thanks for you help!

My pleasure.

David

[jake.t]

(12-09-2014 17:33)DavidHB Wrote:  

(12-09-2014 12:57)jake.t Wrote:  the mp3tag reference is correct, %file_create_date% is an informational tag I can pull. Although it its raw form it is listed with Month first I can reformat the output to the new created tag as I wish to manipulate things a little to come out how I want.

This is where the capability of MP3Tag to search and replace using Regular Expressions (if you can get your head round them!) really comes into its own.

(12-09-2014 12:57)jake.t Wrote:  thanks for you help!

My pleasure.

David

hi David, just an update. this turned out easier to do with convert tag->tag where I could flip things to year-mm-dd (used this "create_date: %year_added%-$num(%month_added%,2)-$num(%day_added%,2) pretty easily and voila a very nice index on essentially the import date to the store with double numbered month and days. Didn't have to get into RegEx at all.

cheers,

Jake

[DavidHB]

(21-09-2014 15:59)jake.t Wrote:  hi David, just an update. this turned out easier to do with convert tag->tag where I could flip things to year-mm-dd (used this "create_date: %year_added%-$num(%month_added%,2)-$num(%day_added%,2) pretty easily and voila a very nice index on essentially the import date to the store with double numbered month and days. Didn't have to get into RegEx at all.

cheers,

Jake

Thanks for posting this. Avoiding the use of regular expressions where possible is good for both temper and sanity, and you have found an elegant solution to your problem. Sometimes, of course (as for instance when you reverse first names and surnames), RegEx is what you have to use.

David