#musicbrainz-devel

sorry back again, got myself lost :( seeing error in the jaikoz logs not that some requests are failing e.g. http://musicbrainz.local/ws/2/recording/?max=15...

Index is currently not available for resource type RECORDING

ops helps if i finish the sentence

requests like above are returning "Index is currently not available for resource type RECORDING" error 500. but all the test queries suggested on the dev setup page and within the read me work fine

hm

the files recording_index is under /home/search/indexdata and has full perms for tomcat

within the setup stuff for the search server you mean?

what happens if you change musicbrainz.local to the address/port of your search server (do you get the same result?)

fyi musicbrainz.local is setup as a host file entry on both querying server and the server itsself

sure i've tried that but let me double check

hm

that URL you pasted isn't valid, must have gotten cut off

yes same result... was moaning befoer it couldnt find host name but host file fixed that

strange its from the jaikoz log one sec let me check it again

should read

oh hang on thats the core musicbrainz server

ok im with it now... sorry its getting late here

that's fine, for /ws/2/<whatever> with a query the search server and main server should show the same thing

if the main server's showing something different then presumably they aren't connected properly

the request to the above returns

Could not retrieve sub-document page from search server. Error: http://musicbrainz.local/ws/2/recording/?max=15... -> 500 Internal Server Error

hence my asking if they're different

ah, okay

I think this may be beyond my expertise then, you should ask someone who knows more about the search server (when someone's around)

then when i send that url direct to search server it returns

HTTP Status 500 - Index is currently not available for resource type RECORDING type Status report message Index is currently not available for resource type RECORDING description The server encountered an internal error (Index is currently not available for resource type RECORDING) that prevented it from fulfilling this request.

oh ok well thanks for trying

yeah

returns the same via IP as well

I guess there's something wrong with the index, or maybe the search server needs restarting or such

if i restart the search server much more its going to storm off :)

i didnt notice any errors whilst the index was building but it did take a good 5 hours so i could have missed something

what would be the most basic request i could use to test it. thus ensure its not jaikoz braking the original request

testing within side the recoreding_index that is?

I guess any recording search would do

something like that ?#

sure, that'd do

mmm, shame as that gives the same error

looking at google its picked up on an old chat session with a gent call Munger who had the same issue

just reading though now looking like i'll need to rebuild index

looks like you came to his aid as well :)

haha

well, glad you found the answer -- what seems to be the matter, from what you found?

(or at least a hopeful answer XD)

still reading ...looks to be a busy log file following the chat is taking me a little longer ... more beer required

ok after a lot of read ... no answer was given ... just a statement that no errors could be seen at the time of building the index

I'll try a little more google and then if all else fails kick of the index build again... is it easy to do just the recording_index on its own? Sorry if its in the manual say i'll go read just dont remember seeing it mentioned

I have no idea, I haven't ever built search indexes :)

not to worry, you've been very helpful.. thank you

well index is rebuilding see what happens FYI command "java -Xmx512M -jar index-2.0-SNAPSHOT-jar-with-dependencies.jar --help" listed the switch --indexes VAL = A comma-separated list of indexes to build (artist,releasegroup,release,recording,label,work,tag,etc etc)

thanks again for your help.... i'll see what happens after index has rebuilt ... but for now its time for bed

ocharles, warp: are there local modifications to daily.sh on astro still? It looks like we haven't gotten a data dump today (but it's day #6 UTC, which should be when it happens)

(or on whatever server runs dumps, I assumed astro)

bah, never mind, guess it's appeared now

CAA must have made it take longer

(well, is starting to appear, that is)

I am new to this and I would like to setup a slave can anyone here help

BEGIN failed--compilation aborted at app.psgi line 21.

[1]red: are you running with carton, and did you run carton install --deployment beforehand?

morning all. any search server experts in at the minute... im still having issues with the "recording" index saying its not there. even after a rebuild... I've ran out of ideas

hm

you might wait around until ijabz is here, he's probably the best person to help

ok... i'll wait as long as i can ...BT are on their way to try attempt number 99999999 and 99 at fixing my broad band so no doubt i'll lose the connection soon

is ijabz state side on Europe. or put another way what time is he normally on/around?

he's in europe, he was joining/parting a bit an hour or two ago but evidently not right this second

hello!

ok, thanks ... didnt know if i need to wait until the early hours of the morning again to catch the right side of a timezone

hello warp

lot of people here with very strange schedules, too, though I don't think ijabz is one of them :P

(e.g.: it's 2am here :P)

I think ijabz has a family with kids, etc.. you tend to have a reasonable normal schedule then.

yup

chiptunes win \m/ and python!

well, I'm downloading the whole dump

not *just* the CAA stuff XD;

(even including *gasp* edits :P)

weirdo :P

(although I do like that I can search the edits on rika)

but only about three times / year :)

yeah

and it's not like I'm low on space anywhere I'm installing a DB

unlike me XD

if I was putting one on my VPS I'd not include edits, but when I want web-facing stuff that pulls from a DB I generally just use rika :P

I can't easily do perl stuff on rika though

which AFAIK is sitting on a terabyte, so :P

yeah, you have to generate static HTML for the public_html folder stuff

mb seems too heavy to run on my vps :)

well, mb.lmfao.org.uk just runs the DB, with mbslave, not the whole perl monstrosity :P

heh yeah, I'm not that insane :P

(heh, versus rika, which I guess runs *several* full perl monstrosities -- but that's the point after all :P)

mb.lmfao is a vps?

(or is on a vps)

yes

warp: http://tickets.musicbrainz.org/browse/MBS-5232 if you get a chance I'd love your comment on what all needs changing for this, I haven't touched Guess Case so you may have a better idea what strings need touching

i18n for guess case stuff

oh meh

The names may be used in comparisons

heh

if we can assume that mode names won't get translated to the same thing between two different modes, will everything still work?

so that needs to be seperated from display names, but otherwise there shouldn't be much trouble moving that out of /static to the regular text.js

(e.g. nobody's going to translate 'English' and 'Classical' to the same thing)

yeah -- I guess I was wondering where to look for those strings to move

Modes/$whatever.js?

ianmcorvidae: I don't know, but that's an evil way to go about things.

(or are those in Modes.js, etc.)

yeah, clearly not optimal, true, separating it out is correct

I think the names go in a cookie

(to remember the selected mode)

ah

so that'd be the part to not translate, I guess, vs. display names

I think it's fine to keep using them for identifiers like that, but make sure those are set from the option value not the next and the other way around.

then add display names for the option text.

s/^/and /

the cookie stuff is in MB/GuessCase/Modes.js

(which calls getName() from the MB/GuessCase/Mode/Base.js object)

yeah