Bug: entries with multiple formats trigger multiple conversions

[flinx1]

Steps to reproduce:

1. Create a book entry that contains say, a LIT and a PDF file.
2. Connect Sony reader.
3. Select Send to device.
4. Get asked multiple times if you want to convert the file. Answer Yes.
5. Check log and see that multiple conversions have indeed been performed.

[kovidgoyal]

That's weird, if yo uhave a pdf file, it should be sent t the SONY directly, since SONYs support PDF.

[flinx1]

I have disabled PDF support in the Device Interface plugin for the Sony, since I prefer converting it to LRF instead. Most of the PDFs I have were not designed/created for PDF to begin with, but is more of a backup format. Still - it shouldn't do multiple file conversions like I described. It did put the LIT file on the reader like it was supposed to thankfully.

[kovidgoyal]

I don't see this behavior, what OS are you on?

[flinx1]

Windows 7 64 bit, running Calibre 0.6.52. It's been like this for several revisions of Calibre at least, but I can't pinpoint when it started since I usually would convert manually to LRF first before using send to device. It's only when I discovered I could change the default priority from EPUB to LRF for Sony readers that I started trying out the send to device functionality.

[kovidgoyal]

OK open a ticket an I'll look at it the next time I'm in windows.

[chaley]

Found the problem, but am not sure how to fix it.

When I start calibre and do copies, I am only asked once. If I go into preferences, do nothing, and press OK, I am from that point asked twice. If I go into preferences again and click OK again, I am now asked 3 times.

--- enter geek mode ---
The problem arises because the the accept branch in gui2.ui.do_config calls create_device_menu(), which seems to register the signal handler again. Somehow the existing signal handlers must be deleted. My guess is each of the instances of DeviceMenu are being held because they are referenced by an event handler. The fix might be to disconnect the existing handlers if _sync_menu is not None, but as this kind of thing is out of my league, I am not at all certain.
--- exit geek mode ---

[Starson17]

Originally Posted by chaley

Found the problem,
...
--- enter geek mode ---
this kind of thing is out of my league
...
--- exit geek mode ---

If geek mode is insufficient, it makes you wonder what kind of mode Kovid has to enter to fix it.

[kovidgoyal]

Originally Posted by Starson17

If geek mode is insufficient, it makes you wonder what kind of mode Kovid has to enter to fix it.

What I typically do is pull the hairs out of my head, one at a time. Eventually, inspiration strikes

[kovidgoyal]

Fix committed.

[chaley]

Another learning experience.

Looking at the fix, I see that the problem was the multiple connections to the button. As the button does not get remade when the menu is reinstated, each connection was remembered. I didn't note that the lifetime of the button was different from the lifetime of the menu.

[kovidgoyal]

Originally Posted by chaley

I didn't note that the lifetime of the button was different from the lifetime of the menu.

The reason for that is that the button (to be precise, the QAction) comes from the .ui file where as the menu is created programmatically and assigned to the action dynamically, each time calibre is reconfigured.

[flinx1]

Just wanted to say thanks for fixing this .