Screenshot here:
http://www.fellandforest.co.uk/p788391640/h2efdcc9c#h2efdcc9c
I also noticed that mnemosyne has to be running on the server for this
to work. Is that correct? I thought the server process might be a daemon
that would run quietly in the background.
Dougie
I've just tried to use the synch server using 2.x. The server will be
192.168.1.4. On the client I've entered the details and it appears to
login ok but then nothing happens. The progress bar doesn't move.
Glad somebody is finally giving the sync protocol a good workout!
> The server will be
> 192.168.1.4. On the client I've entered the details and it appears to
> login ok but then nothing happens. The progress bar doesn't move.
>
> Screenshot here:
> http://www.fellandforest.co.uk/p788391640/h2efdcc9c#h2efdcc9c
Is this related to the other issue you mentioned with long filenames?
From the screen shot, this does not seem like an initial sync, but rather one
that happened after that. Is this correct?
>after a while I eventually get an error window pop-up. Screenshot here:
>http://www.fellandforest.co.uk/p788391640/h1bb47fae#h1bb47fae
I've never seen this before, but could it be a time-out related to network
issues (wifi down, ...)?
> I also noticed that mnemosyne has to be running on the server for this
> to work. Is that correct? I thought the server process might be a daemon
> that would run quietly in the background.
For the time being, the daemon is integrated in the Mnemosyne application
itself.
Peter
a little follow-up on this one.
I've now tried this a few times and it won't sync. It's largely academic
as I'll use rsync and copy the .local/share/mnemosyne data the same was
as I do for 1.x. I'm just curious to see syncing working.
A few screenshots of the error. After a long time on the client (I
haven't timed it, but probably 20 or 30 minutes), I get:
http://www.fellandforest.co.uk/p788391640/h1ed51b00#ha5fa0c8
and on the server I get the following. I don't know how they tie-in with
the client as I wasn't paying any attention. I found them after checking
the screen a few hours later.
http://www.fellandforest.co.uk/p788391640/h1ed51b00#h19da0cc1
http://www.fellandforest.co.uk/p788391640/h1ed51b00#h5422a72
http://www.fellandforest.co.uk/p788391640/h1ed51b00#h1b2b4087
http://www.fellandforest.co.uk/p788391640/h1ed51b00#h1ed51b00
Dougie
PS: There's no wi-fi involved. Both machines wired on the same LAN and I
regularly rsync large file transfers between them.
Not for me, as I want to get this to work :-)
> as I'll use rsync and copy the .local/share/mnemosyne data the same was
> as I do for 1.x. I'm just curious to see syncing working.
The only thing I can think of right now is that perhaps there is proxy
involved in your lan. There is proxy transversal code in the sync protocol,
but it's never been tested in anger since I don't have a proxy myself.
Peter
It's just a straightforward home LAN. server is 192.168.1.4, client is
192.168.1.5, both running Linux Mint Debian Edition. Is there a way of
turning debug on or writing to a logfile? I had a look around for
logfiles but couldn't find any.
Dougie
> It's just a straightforward home LAN. server is 192.168.1.4, client is
> 192.168.1.5, both running Linux Mint Debian Edition. Is there a way of
> turning debug on or writing to a logfile? I had a look around for
> logfiles but couldn't find any.
The best way to help me to debug this is the following:
* start the server on a virgin datadir (with -d ....), create a new database
(i.e. not an imported one from 1.x) and add a single card with an image with a
short filename
* start the client also on a virgin datadir
* both on the client and the server, start wireshark, so that we can log all
the network traffic
* start the sync. (no need to wait for hours, just stop wireshark if the
progress bar hangs.)
* mail me the logs
Note that I won't be able to do any real work on this until after the winter
recess, though.
Thanks for helping me look into this issue!
Peter
I was thinking along the same lines and had a brief test. From the
Windows machine it still complained about long filenames even though I'd
started the server with a new empty 2.x database with just one card. It
was all a bit inconclusive so what I'll do if I have time is freshly
compile 2.x under a test username which will make it easier to cleanly
separate it from my live data.
> * both on the client and the server, start wireshark, so that we can log all
> the network traffic
> * start the sync. (no need to wait for hours, just stop wireshark if the
> progress bar hangs.)
> * mail me the logs
I'll shall give that a try.
> Note that I won't be able to do any real work on this until after the winter
> recess, though.
In the meantime, for your viewing pleasure, you might be interested in
this video:
Using the rather good Teamviewer remote desktop app and the Linux
'recordmydesktop' util I've managed to record a side-by-side session
that shows the client and server machines attempting to sync. The error
messages happen after approx. 10 minutes. The video is here:
http://www.fellandforest.co.uk/p788391640/h2e375e1f#h2e375e1f
although it took a few attempts to get it to upload. I also uploaded it
to my vimeo account but I suspect the playback is the same whether you
go to zenfolio or vimeo:
http://vimeo.com/34121124
> Thanks for helping me look into this issue!
My pleasure. It's an interesting distraction and I'm learning all sorts
of things in the process.
Dougie
The vimeo video (link above) seems to be better under HD than the
zenfolio link.
Manually copying over a database from the server to the client, and
subsequently doing a sync will not work because the machine ids will be
identical. If this is what you did, then at least an issue with the current
code is that it should detect this scenario as opposed to stalling...
Peter
> Manually copying over a database from the server to the client, and
> subsequently doing a sync will not work because the machine ids will be
> identical. If this is what you did, then at least an issue with the current
> code is that it should detect this scenario as opposed to stalling...
Yes, that's what I've done. Well, I've tried both but there's clearly
the risk of detritus lying around from previous attempts.
I think the next step is for me to set up a test account with a clean
database with just a few test cards that is separate from my current
live and untidy deck.
Dougie
OK, that's indeed a separate issue.
> > Manually copying over a database from the server to the client, and
> > subsequently doing a sync will not work because the machine ids will be
> > identical. If this is what you did, then at least an issue with the
> > current code is that it should detect this scenario as opposed to
> > stalling...
> Yes, that's what I've done. Well, I've tried both but there's clearly
> the risk of detritus lying around from previous attempts.
>
> I think the next step is for me to set up a test account with a clean
> database with just a few test cards that is separate from my current
> live and untidy deck.
OK, keep me posted, but I'm guessing doing it the 'proper' way will solve the
problems. Obviously, in the future Mnemosyne should give a useful error as
opposed to hanging, so this is definitely something I need to fix.
Cheers,
Peter
That fixed it.
I created a new account on the client machine and tried syncing from
that. Worked perfectly. Both machines running Linux Mint Debian.
Dougie
That's a relief :-)
Peter