General support topic for Aeva Media (Latest release: July 28, 2010)

Started by Nao 尚, October 14, 2007, 04:28:15 PM

Previous topic - Next topic

Nao 尚

Hmm... Well, if you're getting the very latest revision, you'll need to uninstall & reinstall.
If you're using an older revision (from 2 days ago? Can't remember), you can simply extract db_aeva.php and run it from your server. Or you can run a SQL query from phpMyAdmin, no need to get the latest svn, but I don't know where I posted it.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

clothahump

Downloaded latest version, installed and ran maintenance tools, still unable to upload to my competition albums and according to member group quotas there are no regular members, this just gets worse.

Nao 尚

So it's an SMF issue, not an Aeva Media issue... Mods don't have any single control over what SMF does before you click on the 'Install' button on the next page...
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

petesky

Btw. If you click an image one time it will not increase counter ? This happens also in SMG before. I know this is preview only, but in my gallery mostly users klick preview.

Nao 尚

It increases the seen counter when the item is viewed from inside its dedicated page.
I know this is a very strange way of doing things, but I mentioned that in my to-do-list that it's probably best to simply update the seen counter whenever the user clicks on the item. Just haven't got around to studying that part of my code again...

@sherwin> I have no idea, sorry... You can install it manually and run the db_aeva.php file, but really, if it fails now, it will probably fail again at some other level later...
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Nao 尚

@leftezi> I'm waiting for Karl's answer for now. Hopefully he'll answer directly in one of the topics where you posted.

Quote from: leftezi on January 06, 2010, 10:07:50 PM
When i upload an item in the album with Greek title and Greek description all is OK.
But: If i later edit this item and save it again, then the Greek item-title characters turned to question marks (?? ?? ?? ??). Only the item-title. The description stays in Greek.
I tried with this:

"Testing Greek -> ἔστι δ' ἄρρεν ᾗ δύναταί τι, θῆλυ"

The Greek text is taken from another forum on another topic that also discusses Greek character issues.
After posting the title once, it translated it to numeric entities. After editing the title -- it kept it that way. Didn't have any problems. The aeva_cutString() function ensures that numeric entities are counter as one character (this is a recent change that wasn't in SMG), so it shouldn't be cut too fast...
Then, I copied and pasted the same Greek text a few more times, until it reached the maximum size. It was properly cut.
Then I edited that cut version, and added "123". It showed up. Then I edited it, and added a δ after 123. It then showed as "&#", just as your second message mentions. (Although it is quite strange that I can write so much text while you're limited to 8 characters....??!!)

QuoteThe best option for "Convert UTF-8 strings to entities?" is the "Always convert" but (only) the title-item has problem in the conversion and only after "edit" not by the first save (upload).
Okay, I'll have a look...
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Nao 尚

Leftezi,

- I've fixed the "&#" problem by adding a new function, aeva_trimCutEntities(). Will be in Alpha 3. Unfortunately I realize I may need to add this call to many more places in Aeva Media...
<EDIT> Lol... I already had this in aeva_cutString(), only less well written. Redoing it :P

- Regarding the title/desc difference, here it is: Title doesn't use aeva_utf2entities() (the UTF converter), while Desc does... As a result, well, I guess AM screws up when dealing with the title. I never met the problem because, since I'm in ISO-8859-15 mode, whenever I post UTF stuff in the title field, it is *automatically* converted to numeric entities *by the browser*. My aeva_utf2entities() function simply does this manually for all. Unfortunately, until I myself use UTF on a daily basis, I cannot really help here -- I mean, it's obvious that the fact that UTF8 fails when edited is due to a bug on my side. I remember Dragooon was pretty scared of dealing with complex UTF so I did the functions myself, but I wasn't too sure about how it would work, as I've never, ever used UTF myself in my projects.
So, what I can do:
- Fix the problem... (Can't, wouldn't, won't...)
- Add an aeva_utf2entities() call to the title as well. This is what I'll do.
In the meantime, it would be nice if you could find out whether there are other places/fields that don't seem to like UTF either. Additionally, could you try editing an item to insert your data in it, and then re-edit it, and instead of submitting, just right-click + View Source and search for name="title" and tell me what's in the 'value' field just before that? Does it show plain Greek characters, or unreadable characters, or numeric entities? (Numeric entities = &#1234;&#321; etc.)

Thanks!
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Nao 尚

SVN rev 138

! Limit title length to 255 characters in item add/edit page. Couldn't find a way to make sure UTF characters are counter as several bytes... Ah, well. (Aeva-Gallery.php)
! Item titles should be passed through aeva_utf2entities(), because... Well, because they should. (Aeva-Gallery.php)
! Moving htmlspecialchars treatment of item/desc titles to BEFORE turning them to entities... Might help with the maximum lengths. Hopefully it won't break anything. (Aeva-Gallery.php)
* Updated aeva_utf2entities() and aeva_cutString() to better support strings with a physical size limit. (Aeva-Subs-Vital.php)
* Updated template to match the updated SMF2 RC3 Curve layout. (Aeva.template.php)

Not sure whether I should release this as Alpha 3...?
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

petesky


Nao 尚

Well, easy shortcut: go to page 1 of this topic, click on the Sandbox link (in the message's header), and then click on SVN in the menu ;) And Aeva. And 'Create' or 'Download'.

Basically, I don't advertise the link in plain view to avoid having noobs download the SVN file and attempt to install it. Anyone who wants to install from the SVN needs to remember that SMF will crash when installing it, unless you recompress the *.tgz file into a regular Zip file.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Avail

Yea, I'm having a database issue. I have installed the latest release, and when I go to the MEDIA tab, I encounter this error:

Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation 'ifnull'
File: /.../public_html/Sources/Aeva-Subs.php
Line: 2959


Has anyone else encountered this error?

Nao 尚

You did backup your database before installing AM, didn't you?
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

clothahump


Juan Carlos

Hi,

I just installed the mode and every thing appears ok but when I clic in "peofile" -> "Media"-> "Summary" I have this error:

QuoteError en la Base de Datos: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (latin1_german2_ci,IMPLICIT) for operation 'ifnull'


SELECT
m.id_media, m.id_member, m.title, m.views, m.time_added, m.type, m.num_comments, m.voters, m.weighted AS rating, m.embed_url,
IFNULL(lm.time, IFNULL(lm_all.time, 0)) < m.log_last_access_time AS is_new, IFNULL(mem.real_name, m.member_name) AS member_name,
ft.id_file AS id_thumb, ft.directory AS thumb_dir, ft.filename AS thumb_file, (pt.width && pt.height) AS has_preview,
f.id_file, f.width, f.height, f.height AS thumb_height, f.filename, f.directory, m.approved, m.description, a.id_album, a.name, a.hidden
FROM smf_aeva_media AS m
INNER JOIN smf_aeva_albums AS a ON (a.id_album = m.album_id)
LEFT JOIN smf_aeva_files AS f ON (f.id_file = m.id_thumb)
LEFT JOIN smf_aeva_files AS ft ON (ft.id_file = m.id_thumb)
LEFT JOIN smf_aeva_files AS pt ON (pt.id_file = m.id_preview)
LEFT JOIN smf_aeva_log_media AS lm ON (lm.id_media = m.id_media AND lm.id_member = 2)
LEFT JOIN smf_aeva_log_media AS lm_all ON (lm_all.id_media = 0 AND lm_all.id_member = 2)
LEFT JOIN smf_members AS mem ON (mem.id_member = m.id_member)
WHERE 1=1 AND (a.hidden = 0 OR a.album_of = 2)
AND m.id_member = 328
ORDER BY m.time_added DESC
LIMIT 5
Juan Carlos

Nao 尚

I think I've read about it earlier, but I couldn't do much about it... I've been working on it a bit and here's what I can tell you. I hope you don't mind technical explanations...

One of your smf_aeva_* tables (or maybe all) uses the ut8_unicode_ci collation, while your smf_members table (installed by SMF itself) uses the utf8_general_ci collation. (If you don't know what a collation is -- it's a set of rules for comparing strings: http://dev.mysql.com/doc/refman/5.1/en/charset-general.html)
What you need to do to fix it, is to simply go through all of your smf_aeva_* tables and manually change the collation for string fields to the one used by SMF. It can take some time, though...

What I'd love to know is why SMF specifically asks for an utf8_general_ci collation when creating its own tables, but doesn't specify anything when creating tables for packages like Aeva Media -- instead relying on the default collation provided by the database. Which would, in your case, probably be 'utf8_unicode_ci'. Since they're not the same collation, and Aeva Media is attempting to read both from the smf_members table and other AM tables at the same time in a single query, it returns an error.

Basically, feel free to bring this post to the attention of the SMF team in a support forum. Maybe they'll tell you I made a mistake somewhere, I don't know. I'm too tired to post this to the beta testing boards right now. I'm 'only' 75% sure my reasoning is correct and this is the reason for your issues.

PS: I could also 'force' the query to choose a collation, but I certainly don't want to do that if I can avoid it...
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Arantor

Nao: Good idea, as a change to db_create_table and db_add_column. I'd even suggest adding that on Mantis as a bug actually.
Holder of controversial views, all of which my own.


Avail

Quote from: Naolington on January 07, 2010, 05:39:16 PM
I think I've read about it earlier, but I couldn't do much about it... I've been working on it a bit and here's what I can tell you. I hope you don't mind technical explanations...

One of your smf_aeva_* tables (or maybe all) uses the ut8_unicode_ci collation, while your smf_members table (installed by SMF itself) uses the utf8_general_ci collation. (If you don't know what a collation is -- it's a set of rules for comparing strings: http://dev.mysql.com/doc/refman/5.1/en/charset-general.html)
What you need to do to fix it, is to simply go through all of your smf_aeva_* tables and manually change the collation for string fields to the one used by SMF. It can take some time, though...

What I'd love to know is why SMF specifically asks for an utf8_general_ci collation when creating its own tables, but doesn't specify anything when creating tables for packages like Aeva Media -- instead relying on the default collation provided by the database. Which would, in your case, probably be 'utf8_unicode_ci'. Since they're not the same collation, and Aeva Media is attempting to read both from the smf_members table and other AM tables at the same time in a single query, it returns an error.

Basically, feel free to bring this post to the attention of the SMF team in a support forum. Maybe they'll tell you I made a mistake somewhere, I don't know. I'm too tired to post this to the beta testing boards right now. I'm 'only' 75% sure my reasoning is correct and this is the reason for your issues.

PS: I could also 'force' the query to choose a collation, but I certainly don't want to do that if I can avoid it...

Hi! Thanks for replying. I have converted all of the aeva_* tables to use the utf8_general_ci collation, and a few other tables creating by other mods. Every single table in my forum database has the utf8_general_ci collation, and the error posted still persists. Is there something else that I may have missed?

Thanks,
Avail

K4EEO

Very much appreciated.
I've saved your post for future reference. Thanks!

Tair

Hi!

I hope you will fix some bad bug -

I'm using 2.0RC2. Locale is russian-utf8. Codepage of everything is utf8, all is fine but if create album (with russian name) (with option to decode to UTF (default)
physical folder will looks like

__1090;__1077;__1089;__1090;__1086;__1074;__1099;_

and showed name of folder will cut to like 8 symbols.

If i turn off option to decode to UTF strings:
physical folder will be

С,есС,овый_альбом_РґРІР°

same name in database (which is UTF8 of course). But showed album name is ok.

(i tried to import my albums from forum with cp1251 codepage (converted database to utf8 of course) - but no luck as Aeva can't catch folders with russian names)

Could you please fix all this stuff with utf8 and russian album and folder names? Can't use my old gallery with 4k+photos :(
p.s. tried SMG - same problem is there.

Also, if it is possible - could you please add drop-down menu or smth like that with option like max convertations/second  to converter from SMF Gallery Lite/Pro - because when i use your current converter it tooks like 1 hour to convert DB with 4000+ images - because converter overloads hosting server and i should wait like 10-15 mins for them to unlock my account.

p.s. another question....maybe i'm blind but i didn't find option to move all images from 1 album to another one.

eg208

Iam upgrading from SMG to AM and now I can't save membersgroup Quotas setting.

Advertisement: