ioNiNJA

[o_dog]

YiL: well. Tht was a list =)

Proof, yepp, forgot that 3 times now. =)

So the responses should have dashes now? Will look into it. I know some ftp clients have a hard time.

Show:execute time was a debug option that I added for my own testing and the only reason it's in there is that I forgot to remove it upon release. I will remove it since I see no real purpose for it,and fixing it would eb a headache.

The oversized incomplete dir? I see a hell of a lot of complecations there. wrong files, large dirs, manual work. Should maybe just change the way it picks up total_files and see if there is a better way of doing it? Or jsut peresuade the zip genration that the 90s is dead?

Site rescan workings right now:
site rescan this = what is in the current dir.
site rescan all = What is in the current dir and all subdirs.
Don't think i will change this for 1.0 final. might add more options for it later. Thought about a searchstring options for it. So it would only rescan dirs that match the given search string. if one is given.

I can't really remember why it did the depth travel and cache the dirs. I know there was a reason once. But i'm pretty sure it no longer does that, what i can't remember is if I actually released a version where it was fixed? Will look into it, shouldn't cache it all. Even though the only bad thing with it as far as i can see is the memory buildup.

Think it should preserve the timestamp on rescan, aleready added that option?

The group thing more seems like a damn nightmare for me, but I do like the idea. much better than symlinks. Need to be an option though, since some people want to keep the groups for some reason. Will look into it.

I though about adding a md5 check. Anyone need one of those? I won't be fancy as the sfv check. Only check integrity of a file and then an option to delete or rename. No progressbars etc. Might be useful for OS and stuff?

[Yil]

Just to be clear on the dash thing. All but the last line of a multi-line response need dashes immediately after the numeric code according to the FTP standard. When a client sees a number without a dash it knows it's got the final line and uses that number as the actual result. Thus you could do something like 200- 200- 200- 500 lines and every client would see it as a 500 and thus an error result. However humans tend to get a little confused by that so the best practice is to do what you're doing and make each line show an error like 500- 500- 500- 500 . Without the dashes on non-final lines FlashFXP and my perl FTP module both got really confused.

On the oversized incomplete dir idea, I actually don't think this is very tricky for you. Just leave things the way they are now but add the oversized tag symlink in the parent if the total number of files is greater than the number expected (and delete it if the size gets back to 100%). Leave it up to the user to delete files or whatever to make things right. The problem I have now is that the dir is already "wrong", but I don't have an easy way of knowing that. Definitely make it an option though so people can keep things the way they are if they want.

[o_dog]

i it even possible to upload more than the number of files in the diz? Thought i removed that?

[jjjvipi]

Hello o_dog
thank you for your work with this script!

I have some bugreports/feature requests concerning rescan/resort:

first a little one:
when doing site rescan this the status file looks like this:
[SITENAME] - ( 75MB 16F - COMPLETE ) - [SITENAME]
for newly uploaded stuff it looks like:
[SITENAME] - ( 48MB 10F - COMPLETE - Black Metal 1995 ) - [SITENAME]

one some folders i get a the following error for site rescan this:

06-23-2012 11:51:26 "..\scripts\ioNiNJA\ioNiNJA.itcl" terminated abnormally
--- ErrorInfo ---
integer value too large to represent
while executing
"lsort -decreasing -integer -index 2 "$total_racers""
(procedure "outstats" line 86)
invoked from within
"outstats 0 0 0 0 $file "
(procedure "ZipScript::ZipScript" line 303)
invoked from within
"ZipScript::ZipScript 1 $pf $crc $vf"
(procedure "::ioNiNJA::ZipScript::rescan" line 91)
invoked from within
"::ioNiNJA::ZipScript::rescan "

It only happens on some releases, so i don't think its an error on my side.

When doing site resort all the command is very slow. An option to tell the script just to scan one file (the smallest?) per folder would be nice to speed up things.

Also it would be great to have a command site rescan/resort all *folder*, which would rescan/resort all folders after the folder stated in the cmd. (in alphabetical order)
This would be very usefull for large local archives, which don't run 24/7.

[o_dog]

i've seen the error, but can't track it down. Don't know why it happens or when.

it doesn't check mp3info on rescan, might add that one.

As for the resort all. It doesn't rescan anything, so it doesn't check the files. It only looks up info and sorts it, this takes time, especially if you have covers and artists etc enabled. It then downloads these while it scans. This can't be done inte the background. If you don't want these things then just turn them off in the configs and it will be faster.

I don't get what you mean by site resort all? It does that automatically. If you're in a folder it will sort that folder and all subdirs.

[jjjvipi]

hello o_dog, thank you for your answer!

i confused something while writing my first post, sorry for that.
site resort all is indeed fast (cover download etc is disabled).

site resort mp3 takes forever and the idea just to scan the mp3 infos of one file was for this cmd.

atm i have the following problem:
i have several thousand releases i want to rescan/resort on my local archive PC which it's not running 24/7.
So my idea was to start rescan/resort and write down the last release that was scanned, when i shut down my PC. At the next day i would like to start the process with the first release that was not scanned on the day before.

so it would be nice if site resort mp3 *folder* would start with the specified folder and resort everything that comes (in alphabetical order) after it.

With the current script it would take more than a week till site resort mp3 is done (rough estimate)

i hope this clears everything up

[danon]

i have problem with curl.exe. On some rlses (for example when upload this rls: http://www.imdb.com/title/tt0887883/ ) curl.exe hungs, and imdb script not performed... i must kill curl.exe in taskman, then imdb script is performed but some info is not parsed (for example country). When a lot curl hungs (5 or 6) ioftpd is broke, when i kill curl.exe, ioftpd stand up again...

And i have question - is there any method to call imdb script manually? Or i must reupload .nfo file? (imdb execute on .nfo upload)

EDIT.
When you fexed ioninja, suggests a repair sort in ioTV thx

[o_dog]

site resort imdb when in the dir. It will resort all subdirs.
The ioTV doesn't work? Works here.

[o_dog]

Originally Posted by jjjvipi

hello o_dog, thank you for your answer!

i confused something while writing my first post, sorry for that.
site resort all is indeed fast (cover download etc is disabled).

site resort mp3 takes forever and the idea just to scan the mp3 infos of one file was for this cmd.

atm i have the following problem:
i have several thousand releases i want to rescan/resort on my local archive PC which it's not running 24/7.
So my idea was to start rescan/resort and write down the last release that was scanned, when i shut down my PC. At the next day i would like to start the process with the first release that was not scanned on the day before.

so it would be nice if site resort mp3 *folder* would start with the specified folder and resort everything that comes (in alphabetical order) after it.

With the current script it would take more than a week till site resort mp3 is done (rough estimate)

i hope this clears everything up

can't just scan one file in mp3 dirs. It's not the scan that takes time, atleast not that much. Right now it does alot of other things too. Might look into it later but this is not a bug. A Week? How many releases are there? I might add a speed command for fast resort of mp3s. Wont be accurate though. Right now it check artist names online etc in order to get the right sorting name (still alpha). A Speed command would only use id3 so you will get alot of different sorting names for the same artist.

As for the site rescan or resort and keeping a list of scanned dirs...wont happen. Just to much work and I don't think alot of people would use it. Sorry

[o_dog]

Progress report:
Kind of fixed Status update on groups. It's funky on multiple CD releases and will never be perfect in this so i will jsut let it be as is.
What that means is that the group field on the dir is used for progress report. NO_NFO, EMPTY, INCOMPLETE, NO_SFV, COMPLETE.....etc

I readded rename group to genre. Now there is an option to rename group to genre on FLAC and MP3 upon completion. You can still use progress, but genre will override the complete group if it's enabled.
I have not yet added the DIZ oversized check to this, but it will come (hopefully).

Fixed rescan/resort over multiple dirs. (virtual raid)
Fixed rescan of mp3s, now checks mp3info.

Fixed upload of sfv when deleted, if it was deleted with files in dir and uploaded again. it will now check for the files in the dir and rescan them against the new sfv.

Checking the returned numbers for things (Annoying as hell)





Working on postdel crap.

[danon]

@o_dog, right... ioTV works fine, but sorted with variable %release doesnt work :P

[jjjvipi]

Originally Posted by o_dog

can't just scan one file in mp3 dirs. It's not the scan that takes time, atleast not that much. Right now it does alot of other things too. Might look into it later but this is not a bug. A Week? How many releases are there? I might add a speed command for fast resort of mp3s. Wont be accurate though. Right now it check artist names online etc in order to get the right sorting name (still alpha). A Speed command would only use id3 so you will get alot of different sorting names for the same artist.

As for the site rescan or resort and keeping a list of scanned dirs...wont happen. Just to much work and I don't think alot of people would use it. Sorry

~30k Rels, some more

An id3-only mode is all i need. thank you!

[o_dog]

can see if i can fix an id3 only scan

[SRH99]

o_dog, the progress/update mentioned here https://oss.azurewebsites.net/forum/81732-post310.html, is it yet available for download?

[o_dog]

nopp, no official release as of yet.

Got distracted by writing an archive/freespace script since warchive does not seem to work with shmem for me anymore.

let's try this: http://www.sendspace.com/file/un5hvy