BKKKPewsey wrote:califrag wrote:BKKKPewsey wrote:Was just looking over this thread in case anyone had any useful input and noticed something in my error logs
I think the path is wrong - on a windows install you can specify sub-directory's (domains) for subsonic eg music or subsonic as an option.
Mine is subsonic so path to SS is IP:port/subsonic/index.view
I can not see that in the error logs
(Similar problem on Minisub see
http://forum.subsonic.org/forum/viewtopic.php?f=8&t=7553&start=30)
tsquillario wrote:BOOM! Pushed an update on Git to fix your issue. The default Subsonic install is at the web root not under a subdirectory like yours. I added a setting under Preferences to specify the subdirectory of your installation. So in your case you would put subsonic as that value. Then the path will be correct!
- Code: Select all
http://192.168.0.90:12001/script/LAB.cdn.min.jsFailed to load resource: the server responded with a status of 404 (Not Found)
Shouldn't that be IP:port/subsonic/script/LAB.cdn.min.js in my case
Ah i see what you're saying about the mini-player problem - I may be experiencing the same issue, just gotta track it down.
As for the path... I'm not sure, but the IP:Port should resolve to 'C:\subsonic\webapp' (in your case). When Subsonic runs, it seems to set up the 'subsonic\webapp\" folder as the 'root' folder. So regardless of whether you install Subsonic to C:\subsonic, /mnt/data/Subsonic, C:\program files\subsonic, etc etc. It should create a sub-folder 'webapp' which it uses to serve all the files.
If it were 'IP:Port/subsonic/script/LAb..." that would signify that your C:\ is set up as your 'root' web folder, which should not be the case (huge security risk). I hope that makes sense...
Anyways, I changed a few lines for those .js files so instead of being hard-linked to 'script/LAB.cdn.min.js' it is now '<c:url value='script/LAB.cdn.min.js' />' which should help Subsonic figure out where the files are located.
Drefsab wrote:I was planning on having a look at modding videoPlayer.jsp to change the embedding method to add support for seamless HTML5/Flash support in JWPlayer
"Prior to the JW 5.3 release, the most common methods used to embed the JW Player on your website were object/embed code and swfobejct (1.5 or 2.X). With the release of JW 5.3, we also introduced our own embed method, the JW Embedder, referenced as jwplayer.js. We recommend the JW Embedder when you’re looking to achieve the following:
* Seamless failover between the Flash and HTML5 players.
* Automatic integration with the JavaScript API."
you clearly are a lot more experienced in this type of work and I dont know Javascript at all so working out how to change the embedding method will take me some time. Is this something you would be or plan to look at?
Hrm... Okay this is something I will look into. I may be accidentally 'double-loading' the players... I'm using both the jwplayer.js and swfobject.js .... I thought I read that
both were required at load, but I might just need to include jwplayer.js only (which should fallback to swfobject.js - if i understand that correctly)
I've already updated to the latest jwplayer 5.8 which supports HTML5 and Flash so that's one step forward, i'll have another look at it.
Ultraviolet wrote:Hi califrag. I know it's not ready for production yet and don't mean to hold you to that standard at this early point in your process. I just like to use it daily so that I can give you feedback on things I can't do myself, as well as identify things I, or my users, may like that I could do myself.
My library is large... 500,000+ tracks nearing 4TB. Right now I just have subsonic running on a spare Win 7 machine, but it's a dual core, 8GB RAM fairly beefy machine. Subsonic isn't taxing it at all. The difference in load time is independent of my library size or machine performance. Those are static variables in this equation. Something else changed to dramatically increase load time. It could have been the 4.5 to 4.6 jump or your subsonic branch. Unfortunately, I made these changes at the same time. I'm pretty positive the accordion is not the problem. If I get some free time (not today unfortunately), I'll try vanilla installs of 4.5 and 4.6 and compare performance there. I just thought I'd mention it in case you were aware of some obvious outstanding issue. I'll do more testing and get back to you with the results.
Edit: The manual "Update Search Index Now" functionality seems to be broken in this newest release. Clicking on it yields: "INFO SearchService Automatic index creation scheduled to run every 1 day(s), starting at Thu Nov 17 12:00:00 EST 2011" (the date and time it's schedule to run, but it doesn't actually do anything.)
Okay well your host machine is definitely not an issue then. It seems to be chugging then on the client-side? Please follow through with the vanilla 4.5 / 4.6 installs and let me know if you experience the same issues using the 'official' branch. This will help identify whether the problem exists in a piece of code I've modified or whether it was something Sindre changed (which will take me longer to figure out the cause).
I will watch the Automatic index update item and see if I can fix it. I haven't changed anything on the backend for how this is handled, so it should still work, but I will check this out. I've already gone in and clicked the button and seen that it does generate a log message. I will need to figure out at exactly what point it is failing so I can get this resolved. It seems to be failing on the backend after the log message is generated. The front-end button, which is the only thing I modified, sends a 'signal' (calls a function) to the backend to perform the update.
So now this post is forever long, but it will keep going.
pemholder wrote:I installed the mod today and I am using it at the moment locally besides my regular subsonic installation which is accessed by LAN or Internet.
Things I noticed so far:
Searching does not work, same goes for the simular artist feature.
A feature that I would like to have and that was not created so far in subsonic:
http://forum.subsonic.org/forum/viewtopic.php?t=2532&highlight=@cailifrag:
Maybe you find an easy way to include this in your mod.
pemholder wrote:Ultraviolet wrote:pDid you clear both server and browser cache? This latest .war file has both search and similar artist working great (in FF and Chrome at least).
I did clear the cache.
I installed Subsonic 4.6 Beta2 first, stopped it, then deleted the jetty/xxxx and copied the latest .war-file to c:/program files/subsonic.
Subsonic seems to work. The accordeon shows the artists. I can navigate and play music.
But if I search for any artist and click on any of the similar artists, that are in my database, all I get is: "No matches found"
Edit:
There was not created an index file.
I was used that subsonic creates its index file automatically after installation?
But I noticed, that the index-file was empty. I tried to create an index file by clicking "Update index now" but nothing happed. So I changed the scheduled index update to 1 minute in the future and susonic started to create the index file.
Edit:
Index creating has finished. Searching works.
But I think there is an unwanted behaviour in looking for similar artists:
Example: I play a song from "Albert King". Similar artists suggests "Albert Collins". If I click on "Albert Collins" I get listed all songs and albums with "Albert" and "Collins" in artist name and song title, i.e. "Judy Collins", "Albert goes West" by Nick Cave and so on.
Clicking on a similar artist should only produce results that match the whole string and only search for artists.
It would be great but I think that I am demanding too much, that similar artists should only provide results that are in subsonics database.
I will definitely consider adding in the comment.txt file reading AND/OR some kind of basic .txt viewer thing. This should be relatively easy using jQuery (
http://api.jquery.com/load/ or
http://api.jquery.com/jQuery.get/)
I'm glad you got your search index working, I am not sure why the search index manual refresh is broken, I didn't change anything in the backend, and as for why the index did not get populated on install, no idea on that either, like I said, didn't change anything to do with that, so possible it's a new thing that Sindre changed.
The similar artists is something I pretty much took as-is from the thread, modified very little. I think the fix for the search problem will be to wrap the search query in double quotes which should return only items matching "Albert King" exactly. I will test this and fix it.
Will try to post another update relatively soon. Thanks again for all your testing, and I definitely recommend running this in a TEST environment if possible before you deploy it to your production environment. For me, my 'production environment' IS my 'test environment' lol, but everything seems to work except for the bugs already noted.
Again I just want to re-iterate that this mod was never intended to be put into any production environment.
I started modding this just to get some of the requested features 'written down' (in code) so that Sindre could incorporate them into the official branch.
Unfortunately, I think I've changed so much that Sindre doesn't wanna touch any of my code (I don't blame him).
I'm kind of hoping that my 'mod' will just turn into a testing 'sandbox' where new features can be added and tested before being incorporated into the main trunk.
Right now some of the features I would like to see pushed into the main trunk are Drag n Drop playlist and customized home layout. The only problem is that for Drag and Drop playlist it required jQuery, and incorporating jQuery is what has been the longest and most buggy process.
Basically... Here's where most of the issues are being caused:
In order to have drag and drop playlist we need to have jQuery.
In order to use jQuery (easily) we have to remove Prototype: both jQuery and Prototype bind to '$' as a function.
We can overcome this by coding all the jQuery AFTER prototype and using jQuery's noConflict(), but this is a PITA.
Loading both Prototype and jQuery duplicates a lot of functions: .show(), .hide(), .toggle() etc.
The same issue arises when loading both dwr Util and jQuery: both contain functions for getting and setting values, jQuery's ".val()" versus dwr util's "getValue()" and "setValue()", and also both contain 'cloning' functions which are used to create playlist entries and chat messages.
So we can remove dwr Util AND Prototype, but we have to convert all of the old legacy calls to jQuery's new ones.
For prototype we gotta change the selector: Prototype finds DOM objects by their direct ID, ex $("someInputID").show() whereas jQuery can select ANY DOM object, ex $("
#someInputID").show().
The "#" indicates that jQuery should search by 'id' attribute, similar to how css identifies 'id' by '#'.
To search by class you would use $(".someClass").show(), which would show ALL DOM objects which have that class.
Pretty useful, and now we can target ANYTHING without the element being required to have an 'id' tag.
With dwr it's a little more simple: something like dwr.util.setValue("someInputId", "value") gets changed to $("#someInputID").val("value").
When dynamically generating content, you can look at it like this: "$("#someInputID").val("value")" is 30 char, "dwr.util.setValue("someInputID", "value")" is 41 char, so an 11 char difference * 100 playlist entries = 1100 char difference. 1 char = 2 bytes (in java) * 1100 = 2200 bytes = almost 2kb.
Not bad, plus we don't have to serve (one less HTTP request) OR load (however many bytes for) dwr.util anymore either
But now one more problem... Scriptaculous relies on Prototype, so anything that uses Scriptaculous is gonna break.
Scriptaculous has a bunch of nice effects and other functions that jQuery also has, so just more duplication.
No more prototype, no more scriptaculous, no more dwr.util.... But all the legacy code has to be updated.
For scriptaculous is pretty easy, just change all the effects to jQuery effects, not much else was used.
So now we've shaved off X amount of bytes, at least 3 HTTP requests (more if Scriptaculous was using effects.js, builder.js etc) and hopefully have 'lightened the load'.
However there's a problem, if you don't have javascript, or jQuery doesn't load... NADA. I need to fix this (obviously) so in case of jQuery crashing the app is still usable.
This I plan to do at the end once I've finished getting most of the obvious bugs worked out. I am 'expecting' jQuery not to crash and to load properly.
