ioNiNJA ALPHA - Page 19

vybez · 05-02-2008, 04:40 AM

hi,
keep getting rating: 0 with 0 votes
both when racing and rescanning, but all the other imdb info is correct.
anyone else getting this? have been working before

o_dog · 05-02-2008, 04:44 AM

forgot to update this thread there have been 2 updates. if you used the latest release just replace ioNiNJA.itcl

vybez · 05-02-2008, 05:11 AM

ah ok, was using the 0.5 version.
its working now - big thanks

vybez · 05-02-2008, 06:07 AM

encountered another problem, site rescan all only seems to rescan one level down, ignoring subdirectories of folders?

*nm, was too quick - noticed it rescanned subfolders at the end..*

l.d.m · 05-02-2008, 02:16 PM

when I delete a mp3 release with a lot of files, DELE commands stop after some time and I must logout
I don't know if this is a ioftpd bug or ioninja bug..

edit:
I check my logs dir and I have the attached file,
seems a problem with some chars in file names

Yil · 05-03-2008, 03:39 AM

Decided to use your script to test out some changes in the upcoming v6.5 and noticed a bug in the configuration.

Under [FTP_Pre-Command_Events]
dele = TCL ..\scripts\ioNiNJA\ioNiNJA.itcl
rmd = TCL ..\scripts\ioNiNJA\ioNiNJA.itcl

You probably don't want this from what I can tell. Pre-Commands run BEFORE the actual command and thus BEFORE permission validation and are really designed for permission validation inside the script. What this means is if you try to delete a file or directory for which you don't have permission the zipscript will think that action took place. I tried deleting a file from a dir with a .sfv in it and sure enough I got a .missing file popping up and an incomplete tag, but the original file was still there and everything was complete.

Just move these to FTP_Post-Command_Events and all will be good.

One option you may choose to implement in your config file is to prevent users without certain user flags from deleting files from complete releases. This really only makes sense when you have a site wipe/nuke script also running but in that case it's probably useful. This is an example of what PRE events are useful for.

On a different note, I've run into a stuck/zombie style user problem with ioFTPD a couple of times and one crashlog sent to me looks like ioNiNJA was stuck sleeping forever. I'm assuming this can happen based on a really quick look if a .lock file is leftover from a crash or something. Perhaps a timeout before throwing an exception or validate the timestamp on the lock or something? Another option to consider is doing away with a file lock at all and use the [waitobject] itcl feature. You can name the lock the name of the real path of the file/dir and then no .lock files needed and no cleanup if a crash happens. I'm not sure who uses waitobjects, but they're in the code... doc/itcl.txt has the details.

Yil · 05-05-2008, 10:03 PM

Quick update: I decided to edit the script myself and realized that the waitobject stuff wasn't really suitable because it had a poor interface. You couldn't easily use it in the manner I suggested because close and delete were 2 different actions and there wasn't the more useful close AND delete on last reference action. So I removed delete, and now close does the right thing.

So, until 6.5 my suggestion isn't going to work out real well for you... I'll stick the modified version up somewhere for you to look at and play with once 6.5 comes out.

I also changed the file_id.diz parsing to what I wrote a while back in my fledgling zipscript as it appears to handle more weird cases.

Also, looking into it supporting UTF-8 encoded filenames without really caring that they are UTF-8 encoded but rather just goofy looking names. I saw a mention in your readme about you playing with unicode support. What did you remember not working? I see some .diz/nfo issues when I enable unicode to TCL, but was just curious what you might remember.

Yil · 05-05-2008, 10:21 PM

PS: I can moderate existing forums, but I can't seem to create any new ones or delete old ones... Else I'd move this to it's own area

Best I can do right now is make it a sticky so it's always on top...

o_dog · 05-06-2008, 07:21 AM

it's not a bug that it's pre delete and not post, it reads info from the file before delete. there are some checks that user will be able to delete a file before it creates missing file etc. It's not a perfect solution but working on other stuff right now and this I don't really consider a problem.

The waitobjeckt has never been stable neither has any of the locks.
The lock however isn't really needed anymore it's a leftover from when i had it writing racestats to a regular file. I can just aswell remove it completely even though it has never caused a problem as far as I know.

TCL handles unicode but the arguments that ioftpd passes to tcl are not right, i think it passes all arguments in ascii which make it hard for the zipscript to find the file if filename is wrong, i found a way around it by converting it using the encoding libs but that made the server unstable instead.

What do you mean about the file_id.diz? Never had a problem here either so I have no idead what you're talkign about. But you're allowed to change whatever you want but i would like to ask you not to make them public.

Yil · 05-06-2008, 11:02 PM

Here's the interesting bit with unicode and tcl. ioFTPD is clearly not unicode aware, but it appears to do OK writing goofy looking utf8 encoded file/directory names that on disk appear weird but when viewed back by FTP clients are correct. Thus while not actually unicode aware it just sorta works if you ignore the local filesystem

I'm not sure why TCL using a binary encoding for the passed in arguments wouldn't handle things the same way, but I'm going to be looking into it. Note that this would not support any REAL unicode paths/files not created by the server, but at least it would solve some people's problems until the day ioFTPD becomes unicode compliant....

Actually, if I enable unicode in TCL by distributing the encoding directory again you could convert the utf8 name to utf16 and look for the files on disk and thus be unicode complaint right now. But since ioFTPD wouldn't really know what to do with those names it wouldn't matter anyway, and it would break a lot of other scripts that assume TCL is stupid right now.

waitobject's interface did seem a little poor since close/delete were 2 separate actions. I however have fixed that in 6.5 now, but it sounds like you might not need it.

.diz parsing... corepda releases are wierd and often look like this and currently fail:

Code:

[OS:SMARTPHONE2005] [DATE:08/01/31] [DiSK:o1/
                    o1]

some other types look like this and fail:

Code:

2x6.61mb

and of course some fail to include a .diz at all in any zip file, but if you parse the .nfo you can extract the same information sometimes if no .diz is available although this would obviously have a higher error rate.

PRE/POST: I'm not sure about the pre bit. What information besides the name could you need? Remember, the POST event won't get called unless the file was actually deleted and thus checks for it's existence, permissions, etc have already been done so it's just update the race and adjust the completion tags. Not sure what information from the file itself would be required...

o_dog · 05-07-2008, 08:44 AM

i wont support bad standards, a diz file is needed in releases otherwise it's a nuke. The only way to get aroudn that is to assume that all releases not containing a diz file is complete. And that is just bad, no other name for it. 2x6.61mb is a bad diz file and should therefore be nuked. I know i can do workarounds for it but whats the point. Bad releases shouldn't be allowed to start with.
next version will include fix for the \n thing in diz though. And you will be able to exclude dirs from diz requirement.

It reads the mp3information from it for announce. It was a request added a long time ago. And i never saw any problems with it. You are actually the first one to mention anything about it even though i knew it contained some complications =), all parts of the script uses the same info for formating, announce to ftpd, irc etc. Never saw a point of making all procs have their own announce part. But this creates problems with the postdel since the proc requires the file. I could prolly get around this pretty easy just never saw the point.

At present i'm changing the cookies for themes a very boring and time consuming job and something that should ahve been done a long time ago. Also adding new cookies and formating options.

What i would like is a ioftpd website with collected scripts etc. As it is now most people don't know ioFTPD is under development and scripts are spread out all over the place.

o_dog · 05-07-2008, 07:44 PM

new version out, changed alot in it so will probably contain bugs, plz report them and for god sake do a clean install and don't copy stuff from old cfg

testdrive · 05-12-2008, 08:31 AM

05-12-2008 14:56:08 "..\scripts\ioNiNJA\ioNiNJA.itcl" terminated abnormally
--------------------------- ErrorInfo ----------------------------
can't read "type": no such variable
while executing
"if {$type == "g"} {
switch -- $first {
"Movie name" { set g_movie_name $second ; append samplemessage "| MovieName : [format %-59s [str..."
(procedure "getsample" line 42)
invoked from within
"getsample $sample"
(procedure "rescan" line 122)
invoked from within
"rescan"
invoked from

ioNiNJA.beta.v0.5.0.2-2008-04-26

o_dog · 05-12-2008, 04:49 PM

i do not give out support on old versions. upgrade.
someone uploaded a sample file that wasn't a sample i guess. Fixed in next version.
If this happens all the time there is something else that is wrong.

testdrive · 05-12-2008, 06:59 PM

it dosent i ran a rescan all and it happend after like 50 min of rescanning. happened before also.
btw if i want to remove some information from the sample message like video bitrate can i change that in the theme or i have to remove it from itcl? (i have done this before but i got the error on a unchanged itcl)