Print

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

[Mitch Sowden]

I have grudgingly come to accept that I don’t understand playlists at all or more importantly their limitations / constraints and think that I have expectations that are not possible.

My problem is that I often rebuild the machine/s (Win) that MediaCenter runs on and when I rebuild (on different hardware configurations (paths esp) then those playlists which I so faithfully exported and backed up are useless to me (unless I am doing something wrong?) I can see them but they don’t obediently become additional playlists in my library to use.
My expectation is that if I import a previously exported playlist into MC then as long as I have the source music file I should see the playlist and be able to play the playlist exactly like I could prior to rebuilding the machine. Looking at the problem another way – why export the playlists as backup if you can’t directly import them and use them in the future on another Win/MC build? (BTW, I never backup the library – I always import the music from scratch again – could this be part of my problem?)

I have posted along this line before and searched the Wiki / Net which is why I have come to believe that this is a limitation in the technology / functionality rather than my inability to fully understand playlists. However since I can’t fix the technology but can work on my understanding, I’d ask that someone post some links to info about playlists and recommended settings as well as the limitations of the playlist “technology”

As an aside, I have already downgraded my original expectation (based on feedback here at Interact) that if I made a playlist on MY MediaCentre build, exported the playlist (only) to a USB stick and took it to YOUR MediaCentre and imported it there then THAT would work (assuming the tracks existed on your machine) I still maintain that this is a valid user story and deserves attention but I don’t understand what needs to be fixed for that to work. (Playlist format or MediaCentre?) Taking to the furthest extreme, why can’t a playlist exported from a different media centre (say Win Amp) be played on MediaCentre? (Again as long as the tracks exist) I now (barely) understand that it’s about static absolute paths, actual files etc and the solution is advanced searching but for now if I could have advice on my very real problem (with multiple machine builds and what I should do to reduce my frustration I would be delighted! i.e if I could have specific MediaCentre advice - I'll leave the global problem to others for now.

Thanking you kindly and anticipation,

Mitch
PS I always use the latest MediaCentre (now moving to V20) on Windows (now 8.1 and right now Server 2012R2) I am now also a big fan of storage spaces for what it can do to house the media content - if this is at all relevant to my post...

[~OHM~]

What works for me is....after re-installing windows make sure the drive that houses the files is named the same and has the same drive letter as the original one with the playlist. Restoring a backup will also help as long as the paths are exactly the same....I'm sure someone with more tec knowledge will chime in but this works for me.

[glynor]

(BTW, I never backup the library – I always import the music from scratch again – could this be part of my problem?)

I can't say for sure why or why not exporting your playlists doesn't work, but really it doesn't matter...  This is the core problem.  You're doing it wrong.

The Library is the core database of MC.  It contains all of your Playlists, Smartlists, any customized views you've made, and all of the database records for all of the files you've imported (and all their metadata).  Please read:
http://wiki.jriver.com/index.php/Library

Nuking the Library and re-importing is a pretty drastic step.  And, generally, completely unnecessary.  MC automatically makes Library Backups roughly every two days, and you can make them yourself whenever you'd like.  This backup is a zip file that can be used to restore MC, exactly as it was, on the same PC (or any other PC).  More:
http://wiki.jriver.com/index.php/Library_Backup

As long as the files have the same exact paths (in the same "spot" on the hard drive, with the same drive letter and folders to get to them), then all of the files will come back in correctly when you restore the Library from backup.

Exporting the playlists is generally for information interchange with other people or other copies of MC where you don't want to (or can't) restore the entire Library.  There are a bunch of ways to do this, and it can be complex.  In general, for your described use-case, restoring the Library would be vastly preferable.

[Mitch Sowden]

Thanks Both,

So the consistent naming of the central point of my media (e.g) p: is key and more importantly, the clever stuff that I expected from playlist format is the functionality built into the library? Thanks very much - really appreciate the input - Mitch

[glynor]

I think I understand (that sentence above was a bit confusing to read, I assume due to a language barrier).

But, yes...

The location on disk of the media files is essential.  MC's database (the Library) tracks files by their location on disk.  If they've moved, at all, including the volume name (eg M:\), then MC won't be able to find them and will show "broken" links to the files.

And, the Library Backup contains everything in one shot, so there is no need to export Playlists individually.

[Mitch Sowden]

See http://www.xspf.org/xspf-v0.html#Definingplaylists - It seems that XSPF playlist format is the solution I've been looking for although I've now taken the advice on path on-board. Key info pasted below for reference. My question is then - does JRiver see the same problem and plan to accommodate in the future? Cheers, Mitch

Defining playlists
An XSPF playlist describes a sequence of objects to be rendered. Objects might be audio, video, text, playlists, or any other media type. The function of a playlist is to identify the objects and communicate their order.
 What a playlist is not
The function of a playlist is not to communicate metadata about the composer, song title, etc. Metadata is hard and there are many providers already. We decided that we couldn't compete, and that there was no need for us to try. Moreover, good metadata does not travel well -- every user has to recreate it. Metadata should come from external sources and namespaces like MusicBrainz or Gracenote; this what the XSPF link and meta elements are for.

The function of a playlist is not to store derived information about objects that a user has a copy of. A playlist is not a catalog. A catalog is computed across hard data like files; it stores information like filesystem paths and the contents of ID3 tags. This data has no value on any machine but the one on which it originated. Sharing this data would be a privacy and security violation. Software which needs access to this data has no reason to maintain it in a standard format, because it has no reason to allow access to it. Standardizing this data would be fruitless, because there are an endless number of measurements that software might take and store. Derived information belongs in a catalog.

Things a playlist is not, then, are a metadata format or a catalog. We took care to enable these features, but also to avoid duplicating their functionality, poorly.
 Shareability
If there is no reason for a playlist to be shared, there is no need for a new format. Even a buggy format does no damage if it is created and consumed by the same software on the same machine. The need for a new format only comes up when a playlist travels from one machine to another, for example when it is published on the internet.

One type of shareability is between different pieces of software on the same machine. It is common for playlists created with one application to not be usable by another application on the same machine because of different or conflicting interpretations of the playlist format. M3U suffers from this very badly, because M3U playlists often reference files according to a base path which changes from application to application. The XSPF group aimed to fix this by providing unambiguous definitions.

The other type of shareability is between different machines. For playlists to be meaningful on different machines, they must be able to identify network resources. Audio and video objects are often abstractions like "movie X by director Y" rather than computer-friendly objects like "whatever file can be gotten from the URL http://foo/x/y". To handle this problem, we have provided support for media objects to be found via queries; XSPF identifiers are fuzzy names.

[BryanC]

See http://www.xspf.org/xspf-v0.html#Definingplaylists - It seems that XSPF playlist format is the solution I've been looking for although I've now taken the advice on path on-board. Key info pasted below for reference. My question is then - does JRiver see the same problem and plan to accommodate in the future? Cheers, Mitch

Defining playlists
An XSPF playlist describes a sequence of objects to be rendered. Objects might be audio, video, text, playlists, or any other media type. The function of a playlist is to identify the objects and communicate their order.
 What a playlist is not
The function of a playlist is not to communicate metadata about the composer, song title, etc. Metadata is hard and there are many providers already. We decided that we couldn't compete, and that there was no need for us to try. Moreover, good metadata does not travel well -- every user has to recreate it. Metadata should come from external sources and namespaces like MusicBrainz or Gracenote; this what the XSPF link and meta elements are for.

The function of a playlist is not to store derived information about objects that a user has a copy of. A playlist is not a catalog. A catalog is computed across hard data like files; it stores information like filesystem paths and the contents of ID3 tags. This data has no value on any machine but the one on which it originated. Sharing this data would be a privacy and security violation. Software which needs access to this data has no reason to maintain it in a standard format, because it has no reason to allow access to it. Standardizing this data would be fruitless, because there are an endless number of measurements that software might take and store. Derived information belongs in a catalog.

Things a playlist is not, then, are a metadata format or a catalog. We took care to enable these features, but also to avoid duplicating their functionality, poorly.
 Shareability
If there is no reason for a playlist to be shared, there is no need for a new format. Even a buggy format does no damage if it is created and consumed by the same software on the same machine. The need for a new format only comes up when a playlist travels from one machine to another, for example when it is published on the internet.

One type of shareability is between different pieces of software on the same machine. It is common for playlists created with one application to not be usable by another application on the same machine because of different or conflicting interpretations of the playlist format. M3U suffers from this very badly, because M3U playlists often reference files according to a base path which changes from application to application. The XSPF group aimed to fix this by providing unambiguous definitions.

The other type of shareability is between different machines. For playlists to be meaningful on different machines, they must be able to identify network resources. Audio and video objects are often abstractions like "movie X by director Y" rather than computer-friendly objects like "whatever file can be gotten from the URL http://foo/x/y". To handle this problem, we have provided support for media objects to be found via queries; XSPF identifiers are fuzzy names.

The MC database is far more advanced than any playlist format could ever hope to be.