Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mbdundee]

No, it won't, and I don't think it should. "E:" only makes sense on the server machine, not on the client machine.
Instead, the client machine locations should start with "http://192.168.x.x/...

If you have a different idea, please start a different thread.

From what I see the client receives the schemes as they are setup on the sever. If the server is pointing to a physical location on a disk and you say that the client should point  to "http://192.168.x.x/...  then shouldn't the MC client service interpret the "E:" location from the server and set it to "http://..." for the location? Since schemes can only be temporarily changed on the client how is the http: going to get set if MC does not do it?

BTW: there was a separate thread opened for this issue that received no responses.

[John Gateley]

Using a disk location view scheme only makes sense when you are on the server.

Anyone else want to chip in with an opinion?

j

[JONCAT]

If I load Library Server, obviously am aware that I am browsing the server so MC could display true disk locations to reflect the current state/location of files on the server.

I see the point (i.e. could MC just list the disk locations and point to http://)

I'm not knocking how one would use MC since we all have our idiosyncrasies but you can't tag via Library Server, and aren't there better ways to navigate to docs, photos, etc. via library server than disk location using smartlists & tags? Even if you want to know the true location of a file, don't you get it, but prefixed with the LS format http:\\ ?

I kind of see both sides in that I see LS as a type of remote desktop/control, with limited functionality of course, so it wouldn't be strange to have it reflect the server. BUT even if MC denotes disk location in some undetermined fashion I'm not clear what kind of use one would have for it given the limitations of LS (I'd much rather see seeking introduced for audio files).

Furthermore, your not going to somehow mix local files into a library server-loaded library right? John has a point; the way MC is currently setup: if your filenames list E:\ what's to stop LS from pointing to your local drive where none of the files exist?

I take it you want to somehow modify your LS served library on the client using disk location? I guess I'm unclear on what the actual problem is, or how this is a problem for you, and I think there are better/other ways to accomplish your goal, whatever that may be. Could you explain what you are trying to do? Can't you plug in a folder name minus the actual drive letter and still retain is disk location view scheme? Or tag all the files in some specific location with a custom field and use that tag field on your client for sorting; I think you could mimic the entire disk location scheme this way, with a little tagging.

DC

[mbdundee]

Here is the setup, consider it my lazy mans approach to music organization (yes, we all have our idiosyncrasies).
On the main PC MC is setup using a RAID disk group (E:) with directories for all major categories of music: Rock, Classic Rock, Christian ect. Under each of those directories is a sub directory for artist then a sub directory under the artist for each album.
From MC on the main PC a view is created with Disk Location. Edit the location and browse to the file path of a major category. MC puts in Location (E:\Classic Rock) Add an additional library field of Album and that makes up the view, un-check Auto Name and call it Classic Rock.

From the remote PC connecting to the main PC via the Library Sever this view is not retained, everything is unassigned. I do not want to modify, change or add anything from the remote/client PC just get the view to be the same.

Interesting note, the view from the TIVO service does follow the Disk Location scheme from the main PC/MC system and matches what the main PC MC views are set up with.

Using the Disk location approach only cares about Album within the tag and ignores everything else. Many years of music collection has an incredible variety of tags embedded. (Yes everything could be worked around by spending the time to re-tag everything and I realize MC is very powerful at doing this)
So I guess I am being told to not be so lazy and get tagging.

[Alex B]

Here is an easy workaround:



Just remove the base path from the first view item so that it becomes "Location (root)". The root location is translated correctly when a client downloads a copy of the library.

You can limit the displayed files to a certain drive and folder by adding a search epression like in my screenshot.

Here is an example of a client filename:

m01p://192.168.0.9:61925/E:\Music\Led Zeppelin\Houses of The Holy\01 - The Song Remains The Same.mp3

As you can see the original drive letter and all subfolders are included after the server address and port part.

For example, [Filename]=E:\Music\ would work fine with my example file.

[ThoBar]

Workarounds aside (I dont like relying on workarounds), I would have thought that if MC is in client mode, then it should be intelligent enough to know to automatically prepend the server path to the disk path.

It obviously makes no sense for the library reference at the client end to use a disk location relative to the client machine, but then the library isnt referring to the local machine when you connect to it via a client (it NEVER refers to the local machine anywhere else in this mode).

I would have thought that MC would realise this and automatically add the m01p://192.168.0.9:61925/ portion to the standard E:\Music\Led Zeppelin\Houses of The Holy\01 - The Song Remains The Same.mp3 when in client/server mode.... or am I missing some logical step here?

C.

[scub]

I use [Volume Name] at the root Audio level and most of my child view schemes inherit this.  I only store music files on certain drives and wish to limit this but when I use Media Server it does not convert this.  It took my a while the first time to figure out why the library was blank the first time I saw this but now I just manually modify the root level on the server each time I load remotely.  I think I'll try the workaround Alex suggests so I don't have to change this each time but the ability to Volume Name limits and library server together would be nice.

[lalittle]

Using a disk location view scheme only makes sense when you are on the server.

Anyone else want to chip in with an opinion?

j

Actually, this is not the case at all.  Both "location" and "file path" rules are powerful ways of changing the way MC displays various files in various ways.  These displays/views have JUST as much significance on the client as they do on the server.  Suffice it to say that given the posts here, there are clearly people that utilize these rules in their view schemes, and the fact that they aren't working on the client is effecting them.

I currently have two view schemes that I commonly use that utilize either "location" of "file path" rules, and the fact that I can't use these on the client is absolutely a problem.

Thanks,

Larry

[John Gateley]

Actually, this is not the case at all.  Both "location" and "file path" rules are powerful ways of changing the way MC displays various files in various ways.  These displays/views have JUST as much significance on the client as they do on the server.

The counter argument: location/file path only means something on the computer it is stored on. Media Center provides a lot of tools for organizing your media. You should not have to rely on location to get what you want.

Post one of your view schemes here, see if we can come up with a better alternative...

j

[lalittle]

The counter argument: location/file path only means something on the computer it is stored on. Media Center provides a lot of tools for organizing your media. You should not have to rely on location to get what you want.

Post one of your view schemes here, see if we can come up with a better alternative...

j

Given the posts here by several people that do use the location/file path rules in their view schemes and that also use Library Server, doesn't this itself demonstrate the validity of this idea?  If I'm looking at a library from a client, my assumption is that the rules all apply to the server system, not the client system, including rules pertaining to location/file paths.  If I'm utilizing the server's library, doesn't' it simply make sense to have ALL the server's view schemes work the way they do on the server?

Here is a view scheme where I use the File Path rule:

I have a view scheme that I use to view my secure rip logs.  Since these files are not tagged with Album or Artist fields when they're created, I use "Location" (File Path) for one of the panes in order to group them by artist/album.  I use "D:\Media Library\Audio" as the base path, which results in showing me a list of "Audio" artists, which can be expanded to show their albums.  By selecting an artist and then an album, the file pane will show me all the rip logs for this album.  I can also show all the rip logs for a certain artist, etc. by highlighting an artist instead of a specific album.  I need to use the "File Path" pane, however, in order to do this, so when I look at this view scheme on the client, it doesn't work because the file path info no longer applies.

I have another view scheme that uses the "location" in a similar way.  This View shows me my album folders along with ALL the files in these folders (rip logs, for example.)  Since the "other" files in these folders do not have artist/album tags, the only way I can browse via artist/album is by using the "Artist/Album" folder structure.  I use the "File Path" rule, once again with the "D:\Media Library\Audio" base path, to make it possible for me to browse by Artist/Album (via the folder structure) and see groups of files in each folder (using the "group" feature.)  Once again, this view scheme does not work on the client.

Even if there was another way to do this, doesn't it make sense for it to work this way as well?  I guess my question would be:  Why would I "not" want the location/file path rules to appear on the client the same way they do on the server?  Wouldn't it always be an advantage to have the location rules work this way?

Thanks for your feedback on this,

Larry

[ThoBar]

Along similar lines to lalittle, until MC supports auto-tagging with auto-import, I will always find Disk-based schemes useful, espescially in workflow based scenarios.  Admittedly disk based schemes are used as an interim measure until the media is properly tagged, but that can take quite some time to get done properly (classical for example), as I do not trust online lookup tags.

I exclude from my general library anything in my 'ripped' or 'worklow', but I have a separate disk scheme specifically for these items. This makes it handy, for example, when we get a new CD, rip it, and want to listen to it before I've gotten around to QA'ing the tags. The 'clean' portion of my library is not potentially exposing items in the wrong category (genre, artist etc), but I still am able to easily access new items - the only thing I need to get right initially is the Album name in the file system Directory.

I also find it non-sensical for the client to assume that the server is referring to the client's disks... I just dont get it, when would that be a practical system?

C.

[lalittle]

I experimented with and confirmed Alex's report above -- i.e. that "Location (root)" works, but trying to use anything AFTER the "root" breaks the functionality on a LS client.  If "Location (root)" already works, then doesn't it make sense that adding sub-folders to the rule would also work?  That aside, I agree with confishy about the practicality of allowing location/file path rules to continue to function when a View Scheme is viewed from a LS client.  It offers the obvious advantage of having the client be able to use ALL the server's View Schemes, and as far as I can see there would be no downside to having it work this way.

Thanks again for the discussion here,

Larry

[John Gateley]

Confishy - nobody is saying the server should know about the client's disk structure. I'm saying the client should not assume that the server has a particular disk structure.

Larry - sounds like your schemes are used for maintenance more than playback (the secure rip logs). Unfortunately Library Server isn't set up well to do maintenance, for other reasons that the lack of disk location based view schemes.

All - thanks for the input, but at the moment, I remain unconvinced:
1) In a client-server scheme, the internal details of the server should not be visible or useful to a client.
2) There's no compelling reason for these internal details to be visible.
3) It requires additional (possibly a lot) effort for us to make it work.

j

[ThoBar]

Confishy - nobody is saying the server should know about the client's disk structure

Agreed

I'm saying the client should not assume that the server has a particular disk structure.

Why not? ... so long as the library knows about it. (which I would suggest it already does)

There's no compelling reason for these internal details to be visible.

Thats one point of view, and given it's yours, a weighty one. 

It requires additional (possibly a lot) effort for us to make it work.

That's a different matter (from my perspective). A difficult or problematic implementation can be a nightmare, I concede, may not be worth having.

At the end of the day, I have other methods of getting around this issue (not work arounds mind ), I'm just arguing the point that I don't understand why you wouldn't want it to work, when it seems such an obvious (to me) feature  function of the library server. It seems to be artifically restrictive. I guess it's just a difference of opinion.

C.

[lalittle]

John,

Thanks for the discussion on this topic.  Please note in my following responses that I'm not trying to "win an argument" here -- I'm simply trying to share my personal viewpoints on this subject in the spirit of a friendly discussion.

Larry - sounds like your schemes are used for maintenance more than playback (the secure rip logs). Unfortunately Library Server isn't set up well to do maintenance, for other reasons that the lack of disk location based view schemes.

While it's true that you can't do maintenance from the client, I honestly DO find it quite helpful to be able to check these schemes from the client for troubleshooting/informational purposes -- I did this with my earlier, "simpler" versions of these Views that only used the "root," and therefore that did not run into this limitation.  I only recently discovered the more advanced ways of setting up location-based rules, which is why I only recently was alerted to this issue.  It's simply a lot more convenient to have this capability from the client than it is to always have to physically go to the server system.  In other words, not having these schemes available on the client IS effecting me.

Note also that confishy's example is not for "maintenance," and has just as much validity on the client as it does on the server.

1) In a client-server scheme, the internal details of the server should not be visible or useful to a client.

All I can say is that it IS useful "to me."  You yourself may not find a use location-based view schemes from the client, but I (and others here) do.  This is a subjective issue, and as such, the term "useful" is relative.  To those of us posting here, these schemes are still "useful" from the client.

2) There's no compelling reason for these internal details to be visible.

Again, this is subjective.  From my perspective, it's a "compelling" reason to not have to physically be in front of the server to utilize these schemes, and it's frustrating to have these schemes simply be "broken" on the client.

3) It requires additional (possibly a lot) effort for us to make it work.

This is something that I obviously can't comment on since I have NO idea what it would take to get it to work.  I'm simply voicing my opinion as a customer, and I respect that you have to consider how difficult it would be to implement.

On a side note, one thing that strikes me is that, as Alex pointed out, this already DOES work with the root -- it's just the subfolders that cause these Views to malfunction on the client.  My thinking is that if it works with the root, it would logically follow that it would also work with subfolders.  The current implementation seems "partial" to me.

One final note:  Given that it currently works the way it does, I'm looking into changing my location-based View schemes so that they will function from both the client and the server.  This of course makes these views far less "clever" or convenient to use on the server, but in my day to day use, it's more important for me to be able to utilize these schemes from the client than it is for me to have them function more elegantly.  This is an example of the "subjectivity" of this situation -- it's important enough to me to give up the better browsing capabilities on the server in order to gain the ability to utilize the views on the client.

Thanks again for your discussion of this topic.

Larry

[lalittle]

I'm just arguing the point that I don't understand why you wouldn't want it to work, when it seems such an obvious (to me) feature / function of the library server. It seems to be artifically restrictive.

That's how it strikes me as well.  If it's hard to implement, I understand not doing it, but I just don't understand the argument that it's "not useful" when I DO use it.  It feels strange to have someone tell me that something I use is "not useful."  (Note that by this I mean that I use the "less elegant" version of this on the client by only using only the "root."  I'd use the subfolders if they worked.)

Larry