[Zigg]

any interest in a new filesystem type...possibly ext: ?

what the heck do i mean? currently you can have various file system types...ftp:, xbms:, smb:, etc.... however, once you have your directory from smb: for example, you can't refer to a file on ftp: or shout: or another file system.

why would i want to do this?... one example: i love shoutcast 500 right in my music...ok fine, but what if i want only certain genre's? maybe i like comedy streams only. the shoutcast xml file contains that info. so, maybe i'd like to download the shoutcast xml file, filter it, and publish it in an smb share, or ftp it to the xbox... this new xml file needs to be "read" as a filesystem directory, and presented as files/directories.

there are other examples, which would be best fulfulled by an extensible "filesystem", which would be "read" as xml files, but processed as directories, (sort of like zip and rar files are turned into directories/file lists).

so, maybe a certain file type (.extxml) or prefix (ext would have a certain format .... <label>whatever<label> <label2>whatever bps</label2> <path>shout://www.shoutcast.com/sbin/tunein-station.pls?id=530&filename=playlist.pls<path>

this is just a rough idea so far, and more thought and development would need to go into it.

yes you could do this in python, but why would i want to make a new ui for something mymusic is already doing, and have it integrated with mymusic.. or myvideo.... etc. for that matter, the ext: filesystem could be driven by python scripts (pythonfs:?) where calls from xbmc filesystem are fulfilled by python scripts returning xml.

various kml portals and the kmlbrowser have dealt with this too, but again, why must we have a separate ui? why not have it in the nice (skinned) mymusic ui?

i've been using xbmc for over a year, and now getting deeper into the code. i've never had the need to compile anything new into xbmc before now. but the source has been a great resource for figuring out how to accomplish various things that aren't exactly documented.

i'm now procuring the tools needed to compile and will dig into this project.

i'd appreciate any input!

thanks
zigg

[kraqh3d]

as you said, this file needs to be hosted someplace (ie, ftp, smb, xbms, whatever). all the code necessary to retreive files from these "filesystem" types already exist.

instead, id suggest handling this as as a virtual directory on top of an existing filesystem. when the system comes across a file of a certain filetype (.extxml?), it'll process it, and produce a virtual directory listing. this how archives work.

you seem to be inspired by shoutcast. if this is what's driving this, why not make a shoutcast window. if you look at the shoutcast code, the "limit" in the xml can be extended out. i just tested with a limit of 10,000 items and it returned all the active station. (there's a little over 9500 of them).

the list of all stations can be downloaded when entering the window, and used to populate a database so that it can be easily filtered by genre. (some kind of "refresh" value would be good to make sure the station list is fresh, but u dont want it downloading it constantly.)

[Zigg]

yes, yes, the virtual directory (a la .extxml) sounds like the first swing to take at this.

interesting... i hadn't thought of making a dedicated shoutcast window....... like a switch view in my music? that would certainly deal with shoutcast well... although i was thinking of something more generic...... and your thought of a "database" to search would work..... even extending that idea.... wouldn't it be nice to have a favorites file?

i don't know about other ppl, but i have media spread out all over... various servers, and shared stuff that friends have on their media servers on the internet, plus other media streams like shoutcast...... others in the family may have gathered the media, i might like some of theirs, they some of mine... but not all of it..... so... a "favorites" or a "i'm in a blues mood" or whatever folder hanging around, that has been created on the pc or even better, an xbox database. i'm listening to something, or viewing something... nomatter where it is... "click", add to favorites/folder/subfolder, etc. i'm browsing my friends server.... "click".... i'm not going to copy that movie from his hd to mine... i'll just watch it from his, when i get around to it, but i already have the shortcut saved in my favorites, so i won't forget..... (hmmm... i just had a thought... an option to schedule a low bandwidth off peak time background download if i really did want to get a copy of it, altho i'd prolly make the server do that.)

ok i'm rambling now, but these are some of the ideas swirling around my head... maybe there are too many thoughts there for anyone to make sense of them but me....

again, this needs more thought.... i'll boil this down to a concrete starting project, so i can get started.

any input is appreciated.

thanks,
zigg

[Zigg]

hmmm... after re-reading my last post... i think i just described what ms-windows calls a shortcut..... .xlnk file anyone?

zigg

[kraqh3d]

favorites... that's exactly where i was going... i'm going to be removing the top100 window from music eventually, and a "shoutcast" window would be the perfect replacement for it... and it would be trivial to use the context menu to mark a stream as a favorite in

i have another idea for favorites using the context menu... a "add to favorites" context menu could just put the current item (obvisouly in its xbmc friendly path format into a special m3u playlist.) this special playlist can then be accessed from an virtual window called favorites or something. obviously, the window would need to support multiple media types to work correctly.

or... instead of using a standard m3u playlist file, a database of favorites would work as well.

[Bernd]

sounds great!
a pls file would have the benefit to be accessible also through python.
this way you would be able to put your favorite movie/game trailer in this pls.


bernd

[joecool]

when you add a file/stream to your favorites, how about giving a sliding scale of how much you like it (1-10 or whatever). you'd get a really nice view of the stuff you care enough to bookmark and the ranking would replace the top 100 list.

[Zigg]

so what i see emerging is 2 separate small projects...

1) shoutcast window to more easily browse/filter shoutcast.

2) a favorites folder or (database or pls or extxml however its stored), along with a context menu item to "add to favorites"....

possibly a tiny project dealing with shortcuts, that may merge into one or the other project.

i'm not sure i see the need for an extendable file system anymore, the virtual directory idea makes more sense and accomplishes the same goals.

ok... that said.... i'd not want to be limited to shoutcast.... there are other online media directories out there, and it would be best not to be limited to one or another. taking the flexibrowser that the python folks have done to make it extendable with plugins....

so i'd propose an online media window, which when you choose refresh, or "get media", maybe what it does is run a python script that parses the online media directory of choice via a specific plugin specification.... (shoutcast plugin would be only one of many hopefully)

the plugin interface would be simple... a file of a specific name with parameters (genre, search string, number of items to return, etc) written by the window module, and another file that is written into by python giving the results in a format (database, xml, or pls) that i talked about previously.

the main reason i say have python parse it is because it opens up the development of online directory parsers to a wider group. the performance overhead for this "call-and-return" of python is a negative, but i belive the benifits outweigh it.

alternativly, a dll plugin interface could be designed, with a python plugin dll being coded as well. now its layered, and a potential developer has the choice.

ok... so much for my meanderings on the subject....

more input?

zigg

[Zigg]

joe cool's idea is a good one...... alternatively, if its database based, the favorites could count clicks, or move recent clicks to the top, and a choice to sort by clicks or click timestamp.....

zigg

[Zigg]

i may be getting far afield here....
<flame suit on>

[kraqh3d]

these two projects are things which i feel are sort of lacking at the moment. the shoutcast 500 "bookmark" is a good interim solution, but a true filterable window would be great.

and a favorites screen is a nice to have... especially once there's a true shoutcast window so that you can "save" streams you like. being able to add other items into the favorites is the logical step forward.

the items in the favorites could easily be "ranked" and keeping the number of times viewed is trivial. the music db does this today. its how the top 100 songs and top 100 albums works. the ranking wouldnt replace the top 100 listing, but would just be a different view.

allowing the python scrapers to enter items into the favorites is giong to be more difficult. if you are going to take on this project, i suggest u first concentrate on getting the items from the media windows into the favorites.

[Zigg]

what kind of storage facility for "myfavorites" would you recomend? database? files (a la .pls or .m3u)? something new?

i guess i see either a global "myfavorites" as a database, or maybe any number user named files acting as a virtual directories to store favorites in.

guidence... input...?

zigg
... i think the subject of this topic needs changing.... new thread time?

[kraqh3d]

a database would be better than a file because you'll be able to run sql queries against it very easily to filter the display. you can also keep track of the number of times an item is played, and have a ratings system.