Ian McEwen: Use cmp_bag in Controller::RelationshipEditor test, since attribute order is not consistent across machines.
Yippee, build fixed!
Ian McEwen: Re-add improperly-removed space in a qw() for import
ianmcorvidae
yay :D
misterswag joined the channel
chirlu` has left the channel
Gentlecat joined the channel
itshim joined the channel
rvedotrc joined the channel
zas joined the channel
reosarevok joined the channel
ijabz1 joined the channel
bandtrace joined the channel
Freso
Gentlecat ianmcorvidae: I'm not a fan of the "karma" of a review resetting when the review is altered. That could be one way to "game" the system: if a review gets more negative feedback then positive, go in and change a comma and whoosh, karma is reset.
ianmcorvidae
nobody thus far has proposed that as an option, so I imagine that's good news :P
Gentlecat
:)
rvedotrc joined the channel
nikki
not reseting it is also a way to game it, write a positive review then when you have enough positive feedback, edit it to say it sucks :P
Gentlecat
I guess that's more about community
ianmcorvidae
mostly I'd like it to be possible to say something to the effect of "this review has been edited since some votes were cast, go look at the differences"
and/or be able to alert people that something they've voted on has been revised
whether you hated a review or loved it, you're likely to be interested in the changes!
ijabz1 joined the channel
ijabz1
hi bitmap im looking for this chnage to sql re ordering attribute
ianmcorvidae coudnt get stabke internet conection last night
ianmcorvidae
ijabz1: there's little to no actual change, it's just fewer things being inserted to various tables, such that all series are marked as the same ordering attribute
things went well after they started working, I have a PR up for the MBS changes that need to happen
ijabz1
Hi, as you say instrument description is missing I'll add that
ianmcorvidae
yeah, that's the main thing
ijabz1
ordering attribute is missing from output but should be searchable, so do we want that
ianmcorvidae
I'm not sure re: ordering type, since ordering attribute will in the newest version always be the same that shouldn't be needed (and we can change it later if we reinstate the situation with several attributes)
ijabz1
ordering type is also missing (was never requested in 1st place) so I'll leave that
ianmcorvidae
I'd say ordering attribute isn't useful to put in. I'm not sure about ordering type (which is a value determining if a series is automatically edited by way of the 'number' ordering attribute, or if it's ordered manually by users)
bitmap
I didn't change the schema for ordering_attribute at all, but I did remove it from the /ws/2 output since it's no longer meaningful
ianmcorvidae
ah, if it was left out initially then I'd say it's fine
ijabz1
ah, that was probably why I didnt add it to output
ianmcorvidae
do we have series type? that's actually useful, though I guess I didn't see it displayed in the search
bitmap
and I didn't request ordering_type because I couldn't think of a scenario where it'd be useful
ijabz1
yes that should be there
ianmcorvidae
yeah, I couldn't really think of one either, hence being unsure
ah, yeah, it is there
we need to fix the MBS template to not list ordering attribute/ordering type for display then, probably, but that's not a hard fix
I can put that in my branch
bitmap
which MBS template?
ianmcorvidae
results-series.tt
bitmap
ah, right
ianmcorvidae
you approved that PR anyway though, so I should merge it
but those are removed, anyway
chirlu` joined the channel
rvedotrc1 joined the channel
MBJenkins
* Ian McEwen: Search fixes: /search/editor doesn't exist
* Ian McEwen: Don't force direct search for editor/instrument
* Ian McEwen: Fix release-group to release_group before calling type_to_model.
* Ian McEwen: Don't show ordering attribute/ordering type in series search, since they aren't useful
Also added missing Instrument comment and Xml tests
* Paul Taylor: SEARCH-265:Editor search remove filtering if confirm date null
rvedotrc joined the channel
bandtrace joined the channel
ijabz1 joined the channel
ijabz1 joined the channel
JonnyJD_ joined the channel
bandtrace joined the channel
ijabz1 joined the channel
Nyanko-sensei joined the channel
bandtrace joined the channel
ruaok joined the channel
bandtrace joined the channel
outsidecontext joined the channel
outsidecontext
hi. does anybody know if the first track in a CD TOC actually can have a number other than 1?
sampsyo joined the channel
alastairp
hi all
hi sampsyo
ruaok
outsidecontext: no, its always 1
hi alastairp
Freso
outsidecontext: Though there can be audio before track 1. ("HTOA" (Hidden Track One Audio))
outsidecontext
ruaok: thanks. i just wondered because the method discid_put in libdiscid requires one to sepcify the first track no. and I wondered if that can make sense
JonnyJD_
outsidecontext: from what I remember it doesn't
outsidecontext
actually libdiscid currently does not deal well when you set this to anything else than 1, but I will submit a patch
JonnyJD_
a patch to check that this is 1?
outsidecontext
JonnyJD_, sure, it does. the signature is int discid_put(DiscId *d, int first, int last, int *offsets)
JonnyJD_: that's why I asked. either a patch to make sure it is one or to allow values other than 1
JonnyJD_
from what I remember only 1 makes sense. Maybe you find an old ticket about that
outsidecontext
thanks. I will have a look.
I found this issue because I have a test in ruby-discid that actually checks if values > 1 lead to plausible results, but this fails with latest libdiscid due to the input checking
JonnyJD_
either way, there are different reasons why you would think the first track might not be 1, but even with a data track up front, lots of pregap etc. it is always 1
JonnyJD_, interesting, but that indicates that there can be discs with the first no. > 1
zas joined the channel
JonnyJD_
but not necessarily that they are "valid"
in term of standards
outsidecontext
not sure if this matters. but at least we should be consistent how those discs are handled.
make things a bit more complicated. i thought just fixing discid_put would be sufficient
JonnyJD_
outsidecontext: "The track numbering shall start with the value 01 and shall increment by one"
outsidecontext
JonnyJD_, where have you found that statement?
Freso casts his vote-of-no-special-significance on making libdiscid conform "strictly" to the standard for now, until someone complains about a disc with first track !=1, and then keeping that disc's TOC around for testing purposes in the future.
JonnyJD_
BS EN 609008 1999 british standard does it say in the PDF
that is the closest I found to a standard (difficult to come by.. old.. cost money.. etc.)
outsidecontext
yep
at least we should make sure that reading the TOC with an external tool and using discid_put should get the same results as directly using discid_read
JonnyJD_
yep
outsidecontext
not sure how discid_read currently would react on such a disc
JonnyJD_
and as it goes for copy protected CDs that don't follow any standard: these are difficult either way. I tried my best to make some of these work, but some are just plain broken.
bandtrace joined the channel
Mineo
JonnyJD_: aren't you still a student? we have access to some standards databases over here
JonnyJD_
Mineo: we also have access to *some* standards. I didn't try for this one.
anyways, what I found is good enough. From what I understand this is some version of that "red book", though not the most current one
travis-ci has left the channel
actually, it might even still be the current standard