[Fixed] First tests and some (many) bugs in ioB2

[MidasKing]

First tests and some (many) Bugs (perhaps)...

Well, I installed ioB2-release 1 (until yesterday, still using the v20 :rolleyes: ) and, after following all instalation process, FAQ, Fixes, etc., I am finding some problems... somebody I could help me?

Using: ioFTPD 5-8-5r
ioBanana version: 2 (release 1) - with no ioAutonuke and no trial/quotas
ioA Version: 2.0.5

I tested some commands with weird results:

1)SITE UPDATE

Dont update sorted MP3 and IMDB symlinks

2)SITE UPDATELOG x:/path/to/dupe.log (SITE UPDATE c:/ioftpd/logs/dupe)

Don't convert old dupe.log file (search.log, created by ioA)

3) SITE REQUEST <release> -> Ok
!REQUEST <release> -> NOT work
SITE REQUEST -> list de requests - OK
!REQUESTS -> show "There'no request at the moment"

4) SITE APPROVE <release>
It functions if new releases not started. With upload have started not work.

5) !latests <count> <section>

<count> and <section> not make difference, or either, the result is the same, list 10 new releases of all the sections.

5) SITE STATS

Show only stats referent section 0...NOT all stats. I have two sections. It's will be changed???

6) !wkup, !mnup, !alup, !wkdn, !mndn, !aldn

nothing work, for me only?... perhaps!!!

7) SITE RESCAN

Not undupe .missing files

8) SITE RULES <section> and !section

Waiting new formatting for rules.cfg

Well... it's all... Any help??? :confused:

PS.: Sorry for my mad english!!! :rolleyes: :rolleyes: :rolleyes:
.

[Harm]

1) SITE UPDATE only checks the directories mentionned in $sort(update,general). Also I see that you don't run ioAUTONUKE... a few of its settings are used for the symlinks updater though: $anuke(user) and $anuke(mtab). They should point to a real user and a real vfs file.

2) SITE UPDATELOG won't work if the directory specified for $dupe(dupelogs) doesn't exist. The dupe engine won't either in such case.
Another thing.. the parameter of this command is the path to the old dupe.log file (not the new directory).

3) !request whatever needs to know your uid and gid. This is done using the $ioBinfo(ids,handle). For example, set ioBinfo(ids,Harm) "0 0" tells the bot that the user with the handle Harm has the uid 0 and gid 0 on the server.
The handle is the name the bot uses internally to designate you. The bot has to know who you are (a handle corresponds to one or more irc hostmasks) and you also have to be a trusted user.
Regarding !requests, my guess is that the sitebot can't use the SITE REQUEST command.

4) That's interesting. How long ago was the directory created ? SITE APPROVE uses ioFTPD.log to find the real path of the directory.

5) That's indeed a mistake in the help message of the bot. !latests doesn't take any parameter atm.

6) SITE STATS is an internal ioFTPD command. It has never been able to display the stats for several sections at a time.
SITE BSTATS but its output isn't user-friendly. It's not very hard to change that so if it's not going to be changed in ioFTPD 1.0, it'll be in the next release of ioBanana (waiting for confirmation from the devs though).

7) It might be the same problem as with !requests.. The bot needs the flag 1 to be able to do its job correctly.

8) Yeah, I know I'm late for this and I apologize. I'm working in the UK at the moment and I don't have much time to fully document it.

Hope it helps a bit.

[zykes]

I can agree to the !latests thing, if i go !latests 5 APPS, then it lists all the latests instead of the 5 latests in "APPS".

The same thing goes for !approve. It doesn't work here either.

[Harm]

zykes: Could you actually read the whole thread before replying. I've already explained the !latests issue.

Regarding your !approve problem.. is the bot allowed to issue the SITE APPROVE command ? are you a trusted user (which means your irchost matches one of the trusted hostmasks) ? are you using the command in a defined channel ?

[zykes]

ident@*.bb.online.no os yes :)

[MidasKing]

Thanks, Harm, by the fast answer, but...

1) SITE UPDATE only checks the directories mentionned in $sort(update,general). Also I see that you don't run ioAUTONUKE... a few of its settings are used for the symlinks updater though: $anuke(user) and $anuke(mtab). They should point to a real user and a real vfs file.
I placed the variable user, group and mtab and, then, as reply to command SITE UPDATE the system started to only verify Drive C: e did not make update none.
My settings are:
]###; Default section (do not remove)
set sort(movies,genre,DEFAULT) "D:/FTP/DiVX-1/_Sorted/Genre"
set sort(movies,year,DEFAULT) "D:/FTP/DiVX-1/_Sorted]/Year"
set sort(movies,rating,DEFAULT) "D:/FTP/DiVX-1/_Sorted/Rating"

###; Mp3 by artist, year and genre
set sort(mp3,artist) "H:/FTP/Mp3z/_Sorted/Artist"
set sort(mp3,year) "H:/FTP/Mp3z/_Sorted/Year"
set sort(mp3,genre) "H:/FTP/Mp3z/_Sorted/Genre"
###; Paths to clean
set sort(paths) "D:/FTP/DiVX-1/_Sorted H:/FTP/Mp3z/_Sorted"
###; Paths to update mp3 and movie symlinks
set sort(update,general) "D:/Ftp/DiVX-1 F:/Ftp/DiVX-2 K:/Ftp/DiVX-3 I:/Ftp/DiVX-4/Moviez_BR I:/Ftp/DiVX-4/Moviez_Infantis I:/Ftp/DiVX-4/Moviez_Shows H:/Ftp/Mp3z"

It NOT checked Drives D:, F:,H:, I: and K:, then, he not find nothing to update. :(

OBS.: When upload a new release, the system creates symlinks correcly. :)

2) SITE UPDATELOG won't work if the directory specified for $dupe(dupelogs) doesn't exist. The dupe engine won't either in such case.
Another thing.. the parameter of this command is the path to the old dupe.log file (not the new directory).
The directory specified for $dupe exist and I corrected the command pointing to the old dupelog (seach.log).
But, the format of the search.log (created by ioA) is
127334743562931250|/Appz/Any.release.uploaded.by.any.guy-GROUP
127334743562931500|/DiVX-1/Other.amazing.movie-GROUP
Then, he created ALL symlinks in a same local, called "1" and he deleted the old search.log (this not cause problemas for the SITE SEARCH *string*???)

OBS.: When upload a new release, the system creates the new log correcly. :)

3) !request whatever needs to know your uid and gid. This is done using the $ioBinfo(ids,handle). For example, set ioBinfo(ids,Harm) "0 0" tells the bot that the user with the handle Harm has the uid 0 and gid 0 on the server.
The handle is the name the bot uses internally to designate you. The bot has to know who you are (a handle corresponds to one or more irc hostmasks) and you also have to be a trusted user.
I think this settings are correct: I use my handle (MidasKing), same in admins, my UID and GID. The problem is the reply of bot :
|XL|> Current requests:
|XL|> There's no request at the moment
and exists requests hanging (The command SITE REQUESTS show it)

4) That's interesting. How long ago was the directory created ? SITE APPROVE uses ioFTPD.log to find the real path of the directory.
I go to make more tests... :confused:

5) That's indeed a mistake in the help message of the bot. !latests doesn't take any parameter atm.
Sorry.... My mistake... :o

6) SITE STATS is an internal ioFTPD command. It has never been able to display the stats for several sections at a time.
SITE BSTATS but its output isn't user-friendly. It's not very hard to change that so if it's not going to be changed in ioFTPD 1.0, it'll be in the next release of ioBanana (waiting for confirmation from the devs though).
Then, it is possible that in a next version this is contemplated? That is very important for me (for others also, of course!!!).

7) It might be the same problem as with !requests.. The bot needs the flag 1 to be able to do its job correctly.
Hummm... I think that not. My bot have flag=1M and the command SITE RESCAN is not a bot command, right??? :confused:


Thanks again, a gread hug and congratulations for the new work...

[MidasKing]

Complementing...

The file Current_dirs.log and current_dirs.log_tmp exists and they are empty...

This is correct???

[Harm]

First of all, I made a mistake in my first reply. The whole paragraph 7 was also related to the !wkup, !wkdn, !whateverstat problem... and this made me skip the SITE RESCAN thing.
For SITE RESCAN, it's not unduping the .missing files because there's no need for it. ioB2 release 1 doesn't do file dupechecking.
Case 7 closed.

1) Let's have a look to the sample configuration file. ###; Paths to update mp3 and movie symlinks
set sort(update,general) "/REQUESTS"
This variable is a list of virtual paths to check.
Case 1 closed.

2) The old dupe.log is supposed to be your former ioBanana dupelog, not ioA's searchlog. It deletes the file because the old dupelog shouldn't stay (it'll no longer be used).
Case 2 closed.

3) It's your handle, but does the bot know that you (on irc) and this handle are the same person. If you're using telnet to chat the bot (which is highly insecure), it's probably not. Add your irchost to your account on the bot using the .+host MidasKing MidasKing!midas@your.cool.host.name command.

ioBanana expects the format of the requestfile to be as follow: Request_Line = " [%##] [%-10user] -> %request"

4) Please tell me as soon as you have the results of these new tests.

5) Case 5 closed.

6) As I've written, it has always been like this before. And (as I've written again), it'll make it to the next release if it's not integrated into ioFTPD itself.
Case 6 closed.

[_panic_]

6) SITE STATS is an internal ioFTPD command. It has never been able to display the stats for several sections at a time.
SITE BSTATS but its output isn't user-friendly. It's not very hard to change that so if it's not going to be changed in ioFTPD 1.0, it'll be in the next release of ioBanana (waiting for confirmation from the devs though).

many appologies harm, i totally missed this yesterday. if SITE BSTATS isn't that user friendly, i'm inclined to change it, but i can't confirm what it will change to just yet. i know that doesn't help all that much, except to confirm that SITE BSTATS might indeed change.

[Harm]

Actually, SITE BSTATS is an ioBanana site command. If you could change the SITE STATS command so it supports multiple sections at a time, I'm sure the users would be happy.

[MidasKing]

Case 1 closed. definitively :D :D :D

2) The old dupe.log is supposed to be your former ioBanana dupelog, not ioA's searchlog. It deletes the file because the old dupelog shouldn't stay (it'll no longer be used).Then, how to make to create new ioB2 dupelog? It's possible to adapt the code to form new dupelog from the existing physical base? Or we must look "alternative" solutions, like editing search.log to use site updatelog with no problems?

Case 2 closed. and reopen?? ;) ;)

3) It's your handle, but does the bot know that you (on irc) and this handle are the same person. If you're using telnet to chat the bot (which is highly insecure), it's probably not. Add your irchost to your account on the bot using the .+host MidasKing MidasKing!midas@your.cool.host.name command.
I found the source of the problem: Request_Line = " [%##] [%-10user] -> %request" (in ioA), had a space less.

Case 3 definitively closed. :D :D :D
4) Please tell me as soon as you have the results of these new tests.
Well, SITE APPROVE <release> and !APPROVE, after some tests and verification of the configurations, NOT function...

Case 4 still open. ;)

Case 5 closed
About case 5: the text in !help <|XL|> !latests [count] [section] : shows the last [count] releases uploaded in [section] (defaults to 10 releases in all sections). to induces in errors. It must be changed to: !latests : shows the last 10 releases uploaded in all sections).

My 10 cents :D :D :D

And... new tests... then new cases :rolleyes: hehehe

SITE CLOSE and SITE CLOSESERVICE answer with: command not understood...

Until the moment, is this!!! :rolleyes:

[MidasKing]

Hummmm!!!

ioB2 DON'T force send .SFV first????????????? :mad:

If "yes"... I don't understand!!!!!!!!!

[Harm]

Then, how to make to create new ioB2 dupelog? It's possible to adapt the code to form new dupelog from the existing physical base? Or we must look "alternative" solutions, like editing search.log to use site updatelog with no problems?

I think it's possible to use ioA searchirc command to regenerate a dupelog but it's a bit tricky. I'll study ioA searchlog format and implement it for the next release.

Well, SITE APPROVE <release> and !APPROVE, after some tests and verification of the configurations, NOT function...

Ok, I'll do some more tests on my own.

SITE CLOSE and SITE CLOSESERVICE answer with: command not understood...

You have to install ioCLOSE (http://www.inicom.net/pages/en.ioftpd-scripts.php?id=60) which is a separated script.

While I'm at it, I suggest you install ioCOMPARE (http://www.inicom.net/pages/en.ioftpd-scripts.php?id=128) and ioSTATS (http://www.inicom.net/pages/en.ioftpd-scripts.php?id=132).

And indeed, it doesn't force sfv first.

[MidasKing]

And indeed, it doesn't force sfv first.

Hummm! This isn't good!!! :confused: :mad: :eek:



Well, Harm, we will be waiting, anxious, ioB2-R2 that, certainly, will be full of new features... ;)

A great hug and good luck!!!

[MidasKing]

Another problem... (maybe a bug?!?!) :(

ioBanana NOT create symlinks if some of the variables (opening date, screens, etc) will not be available (NA) :mad:

[Harm]

Hmm, I guess I'll have to create a poll/thread to know what features are considered usefull. I don't use force sfv first myself (not that it's hard to add). Any suggestion for the first proposals ?

I couldn't (and still can't) see the point of having a sorted symlink in, for example, the year directory when there's no information available about the year. It's even more obvious to me for rating and genre. Note that it skips creating the symlink on a per variable basis, which means if you don't have the rating but you have year and genre, the year and genre symlinks will be created.
Could you explain why you need sorted symlinks for not available infos ?

[richto]

I would say priorities should be:

1) Provide rules info and update documentation
2) Fix all known bugs in what we have now
3) Then whilst doing the above create a poll for new features. Pick best options and allow a vote on them by those that paid into scripters pool.
4) Release bugfixed core
5) Work on new features.

One suggestion I have is alias all commands so that glftpd equivalents are handled - eg !df MNUP MNDN etc. This will save no end of confusion.

A second suggestion would be a bug / issue / features tracking system. as per Sourceforge, etc.

[MidasKing]

Hmm, I guess I'll have to create a poll/thread to know what features are considered usefull. I don't use force sfv first myself (not that it's hard to add). Any suggestion for the first proposals ?
Well, only one at the moment: force .sfv and .nfo in specific paths to my choice(this is very important). As in ioBanana v20 p.ex. :)

I couldn't (and still can't) see the point of having a sorted symlink in, for example, the year directory when there's no information available about the year. It's even more obvious to me for rating and genre. Note that it skips creating the symlink on a per variable basis, which means if you don't have the rating but you have year and genre, the year and genre symlinks will be created.
Could you explain why you need sorted symlinks for not available infos ?
Sorry, Harm... but the told error was happening only for a specific .nfo of one specific group. Already corrected (not ioBanana error) and, in truth, was not very important... ;)