people going out of their way to thwart mylar search?

Post any problems / bugs / issues that are Mylar-related in here.
Post Reply
leaderdog
Posts: 218
Joined: Sun Apr 26, 2015 1:52 pm

people going out of their way to thwart mylar search?

Post by leaderdog » Sun Sep 30, 2018 12:34 am

I know newsgroups just said goodbye to another poster fortunately to be filled with another. But there were a mess of titles with bonkers layout which of course Mylar can't pick up.

2018.09.19 Marvel Week+ "X-Men - Gold, 2018-09-19 (36) (digital) (Glorith-HD).cbz"
More 0-Day of week 2018-09-26 - "Mighty Morphin' Power Rangers, 2018-09-26 (#31) (digital) (Glorith-HD).cbz"
2018.09.19 Marvel Week+ "Mr. Mrs. X, 2018-09-19 (03) (digital) (Glorith-HD).cbz"


I don't know if this is a new trend, but latest was 2.4 days ago. Is this something Mylar could read or is it just a mess to pick up?

Would be nice if people could just agree on a finalized release format to make everything run smoother.

User avatar
evilhero
Site Admin
Posts: 2274
Joined: Sat Apr 20, 2013 3:43 pm
Contact:

Re: people going out of their way to thwart mylar search?

Post by evilhero » Wed Oct 10, 2018 3:33 pm

It's not really about thwarting Mylar/automated applications - it's about idiots trying to force 'standardisation' using names that aren't what was the original scanner intended. It does look like however, that in the past week or so the naming has gone back to the normal method of naming (ie. scanner-release naming), which should mean that things will be found as per normal again.

All of the files you linked, are all .cbz - which is almost always not how items are released (they're like 99% cbr). Having them be cbz files would indicate that this poster to usenet got the files, renamed them to his 'standard' and then probably metatagged them (cause you know, again standardisation right?)

Mylar can't parse '(36)' being in a filename properly cause it literally could be anything within the brackets aside from it being an issue number (remember those lovely alpha-numeric issue numbers). However, it can properly parse it if it was '(#36)' as Mylar then knows that THAT is the issue number. The search parser algorithms need to be updated so that it uses the same methods of parsing as the file checker (right now they each have their own separate search functions which are completely different), but that's a big code change due to how all the parts fit together and rely on the search results aspect. Even if they were both using the same, it would only think the last example (#36) above would be valid and would ignore the first (36).

Someone should try to setup a standardisation committee for this kinda shit eh? ;)

Post Reply