SoftwarePlugin

Erland Isaksson edited this page Dec 31, 2015 · 1 revision

General

This is a very preliminary helper plugin for getting tag information from SBS. We don't have anything to import it into the SMD database yet, so you can't do much with it besides calling the JSON commands it offers.

The source code is available here:

To install the plugin, you need to setup the following repository file in SBS Settings/Plugins:

After that you should be able to install the "Social Music Discovery" plugin through SBS Settings/Plugins

Bundling of SMD Server

The SMD Server is bundled with the plugin and launched at Squeezebox Server startup and shutdown at Squeezebox Server shutdown. The SMD Server database is configured to:

  • Use SBS MySQL instance on port 9092 if available
  • Else use an Apache Derby database stored in the SBS cache directory

It is also configured to put a smd-server.log file in the SBS log directory.

The plugin will very if the smd-server jar file is included at startup and if there isn't, it will just start the perl plugin part.

Bundling of SMD Frontend

The SMD Frontend is bundled with the plugin in the "full" distribution, it's started through the "Social Music Discovery" link under the "Extras" menu in SBS web interface. You can also select to open it as a new window to get a bit larger window.

The SMD Frontend bundled with the plugin is signed, so the user will have to approve that it isn't restricted to the web start sandbox the first time it's launched. It will take some time to launch the frontend the first time, this is caused by web start and Apache Pivot and the SMD Frontend jar file size.

JSON interface

Currently the plugin support two JSON commands:

socialmusicdiscovery tracks start:0 size:20
socialmusicdiscovery scannedtracks start:0 size:20

start/offset is use to get the information in appropriate chunks, for example 20 tracks at the time.

The "tracks" command reads tags directly from the Audio::Scan module in SBS, the "scannedtracks" presumes that you have done a scanning operation through the Social Music Discovery plugin before the command is executed. I'm not sure we need the "scannedtracks" yet, I only included it to improve the performance of the command by making it possible to pre-scan the tags in advance.

The commands return a JSON response which contains a list of tracks and for each track it returns:

  • url
  • full file path
  • calculated smdID
  • An array of tags that have been scanned

To execute the command and look at the result, you can install the "Poster" add-on in Firefox and then issue a request to the url: http://localhost:9000/jsonrpc.js You need to set "Content Type" to "application/json" and in the "Contents to Send" text area enter the command in JSON syntax, for example:

{"id":1,"method":"slim.request","params":[ "-", ["socialmusicdiscovery", "tracks","offset:0","size:20" ]]}

Send the command with a POST.

The smdID is currently calculated as:

  • md5-audiooffset-audio size For example:
  • 681a0f25a2a31776be927c08f91d2131-00001257-01bfe2eb

Note that the above smdID calculation is a temporary solution, the goal is to have a SHA256 based version. The current version it will even give different results in 7.5 and 7.6 which is really bad. The reason it gives different results is that the 7.6 version of Audio::Scan supports to calculate the MD5 based on a section in the middle of the file while the 7.5 version doesn't. We can easily fix this part by not using it, but that also means that we need to include more bytes in the checksum to ensure uniqueness.

If you like to look at the result of the scanned data it's stored in two tables in the SBS database:

  • socialmusicdiscovery_tracks (track url + smdid)
  • socialmusicdiscovery_tags (tags for a specific smdid)

Questions

  1. The current solution reads the tags directly instead of getting the information from SBS database. The result is that we can get access to raw results instead of loosing information due to SBS default mapping which has to map the information to SBS limited database structure. Do you think this is a good idea or should we instead try to get the information from SBS database ?
  2. The current solution have no configuration what so ever, the tags supported are hard coded in the code and the mapping between MP3 ID3 tags are also hard coded, for example TPE2 is hard to BAND. My thoughts is that we shouldn't need to have a very configurable plugins since additional metadata probably will be added through the SMD user interface or SMD online metadata import modules. SBS import is only used initially to get the initial library up and running. We can still have options in SMD interface during import where it's possible to adjust that you want a BAND to be represented as an ALBUMARTIST Contributor relation in SMD. Do you think we need a more flexible configuration in the plugin part ?
  3. It would be great if someone with a bit larger library to try the scanning operation, install the plugin and go to Extras/Social Music Discovery and initiate a scanning and report back how long time it takes. Also look in the server log and see if you get any constraints error which would be an indication that the temporary smdID calculation isn't good enough.
  4. Review the SORT_TAGS and MAPPED_TAGS arrays in the following file and let me know if there is some obvious tag which I've mapped incorrectly or missed to include. I suspect we need to adjust the YEAR related tags a bit since they are currently all mapped to YEAR which is probably a bad idea since we have year in multiple places in the SMD domain model. * http://socialmusicdiscovery.googlecode.com/svn/localserver/trunk/src/smd-plugin/src/main/plugin/Scanner.pm
  5. Thoughts regarding how we want the user interaction to work during import from SBS is also welcome. We could just have a background operation that imports and writes directly to the SMD database but my personal feeling is that it feels a bit dangerous, especially for incremental import where I don't want the limitations of SBS database to be spread to the data in the SMD database. My thoughts so far has been to do the import to some temporary area and then allow the user to do adjustments before it's written to the final SMD database. Anyway, does anyone have any thoughts/ideas how we might want this to work from a user perspective ?
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.