On 22/12/2011 15:20, Peter Bienstman wrote:
On Thursday, December 22, 2011 01:51:05 PM Dougie Nisbet wrote:
On 22/12/2011 13:02, Peter Bienstman wrote:
On Thursday, December 22, 2011 11:05:31 AM Dougie Nisbet wrote:
When I run 2.x for the first time and it imports the 1.x database it
produces lots (about 50+) import errors with a window pop-up 'media
not
found'. This is a slight nuisance as I have to hit the space-bar to
acknowledge each message.
Is this with the latest beta? I thought this was fixed to only show a
single error message in situations like these.
yes. happens in both Windows and Linux.
Are we talking about 'true' missing files here, or about the long filename
issue? in other words, do you get a dialog with a friendly error message, or
one with a hairy stack trace? In the latter case, what is the exact stack
trace? The other one you showed was only for the sync process.
No, sorry, my mistake. I've committed the sin of not obeying the golden
rule: 'only change one thing at a time'. I've misread what's going on.
When I renamed the file to a shorter version, I'd also done a
system-wide 'make install-system', so of-course my images had already
moved on. The image with the long-filename was now under ~/.local/share.
When I renamed the image in its new and correct location, it no longer
produced an error on the windows sync, so my comments/assumptions that
the sync was looking at the database and not the physical file were wrong.
However it's clear that I have dozens if not hundreds of images that
have filenames that are too long. I shall need to do some serious
head-scratching on this one.
BTW, the reason your long filenames worked on 1.x under Windows is probably
because the standard location of the datadir is now a longer string in 2.0...
No, this is the first time I've ever tried the Windows version, and I'm
only giving it a try because of the sync mechanism. I've never used the
Windows version before today!
netbook, laptop or desktop. After importing into 2.x I notice that when
editting individual cards that the HEIGHT= is still there, but I can
presumably only modify them on a card-by-card basis as the database is
no longer stored in a flat ASCII file, but in an SQL database.
In theory, you should be able to do everything what you did on txt files either
by using libmnemosyne's API to modify cards, or by directly modifying the SQL
database (although the latter has the disadvantage that the sync process does
not know that a card has been changed.)
Or, even better and easier, you can write a filter plugin which at run time
adds the correct height tags depending on the machine you are on :-) Look at
'mnemosyne/example_plugins/filter.py' and change the 'run' method to a method
which adds the height tag.
So many interesting distractions and so little time! It does sound tempting.
Dougie
--
You received this message because you are subscribed to the Google Groups
"mnemosyne-proj-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mnemosyne-proj-users?hl=en.
