Hi Michael, mherger wrote: > Good to see such an initiative! This is something I've been wanting to > do > for years... > > > This is not, and is not meant to be, a complete replacement for the > > normal web interface. There are no settings, plugins, internet radio > and > > other advanced functionality. > > I guess this will be a killer for many potential users. Would you be > interested in using the SlimBrowse menu as used by other controller apps > > to get access to those features? > Certainly, I just hadn't time to have a look at this topic. Maybe you can point me to the right place - I only noticed the "radios" cli command, and haven't come across the SlimBrowse menu.
mherger wrote: > > > > - Not tested with other browsers > > I've only run a few quick tests with Opera, and it seemed to work quite > ok. > Great. Since you are on MacOS, did you get a chance to try Safari? As it's WebKit-based, I'd assume it should work, but you never know... mherger wrote: > > > > Installation > > Download the 3 attached zip files, rename LMSnewGUI.dist.z01.zip to > > LMSnewGUI.dist.z01 and LMSnewGUI.dist.z02.zip to LMSnewGUI.dist.z02 > and > > unzip the LMSnewGUI.dist.zip file (I had to split it due to size > limits > > in this forum - you'll need to use a zip program capable of > processing > > split archives) > > This might be the big problem #2 for many. I actually had to google to > > figure out how to extract this on my mac. The command line zip/unzip > tools > didn't recognize parts 1 & 2 due to the additional .zip extension. Once > I > removed that they would work. > Well, the forum doesn't allow me to upload *.z0? attachments, and I actually did mention that they need to be renamed. mherger wrote: > > Do you have some web space somewhere? Or a dropbox account or something? > > It would be much easier to install if you could provide a simple XML > file > to be included in the plugins list. > True, but atm I don't have any of those. If there is enough interest in this plugin, I guess I'd have to provide something like that. mherger wrote: > > I have a few implementation questions: why did you decide to implement a > > JSONP handler when most of the features could have been implemented in > JS > directly using json/rpc? JSONP would only be needed if you wanted to > load > the skin from one server to control another instance on a different > server. Otherwise you can use simple json/rpc. If you want to implement > > search/browsing on your own, you'll risk that users will complain > because > it'll behave slightly different than the "original". It's probably > easier > to use the existing implementation than trying to re-invent that wheel > in > most cases. In particular the handling of contributors can vary easily. > It would certainly be easier, but the available commands have a number of limitations, either in functionality or in performance (or I didn't understand them well enough ;-) eg. - the GUI enables you to add/remove an arbitrary number of artists/tracks in one operation. The available commands are limited to a single artist/album - the available commands return track ids, so I'd have to send another request to get the meta information - songinfo/tracks command seem to only take a single track, so I'd have to send one request per track to get the meta information - the GUI displays album duration, which is not returned by the album command, so I'd have to send an addition request etc. With my approach, I can do all of these operations in a single call to the server, and also take advantage of dbi prefetch to minimize database queries (which makes a huge difference e.g. when displaying a large number of tracks, for which I need the album, artist, genretracks, genre, persist and comment tables) mherger wrote: > > And you should not require to ship the SqueezeJS files, as they're part > of > the server distribution anyway. > The Base.js included with the server doesn't work with Ext4 due to API changes. Additionally, there a two issues in it I'd consider bugs: - SongParser doesn't return bitrates for local tracks - the playlistchange event gets fired for just about every change on the player (e.g. play, pause, track change - basically the same as playerstatechange). That might be a semantic problem, but I wouldn't consider the play list changed just because it's stopped - and there is no other event I could use to detect an actual play list change (tracks added, deleted etc) Thanks for the feedback! ---- Roland ------------------------------------------------------------------------ Roland0's Profile: http://forums.slimdevices.com/member.php?userid=56808 View this thread: http://forums.slimdevices.com/showthread.php?t=98186 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
