Media is not being downloaded

[CodingFree]

Hi,

I have the following settings:

copy_media: true
  download_media: {
    photo: true,
    document: true,
    audio: true,
    video: true,
  }

But the directories at the path ./output/media/ are empty. They have the same friendly name than its user, but they have not a single file.

Am I doing something wrong?

[tvdstaaij]

Your configuration is ok (as long as you're running telegram-cli and telegram-history-dump on the same machine) -- I just tried the same on one of my dialogs and it does create files in the output media directories. However, I do know that telegram-cli's media downloading can be really buggy, varying with the account that is using it and the dialog being backed up. If this is the problem then the console output of either program should give some indication of this (error/warning messages, unhandled signal crashes, hanging on a download for a long time. ...).

If telegram-cli's buggy media downloading is the problem then there is only so much that can be done on the telegram-history-dump side. If there are no telegram-cli crashes involved you can try an "experimental treatment" of sorts. There is a pending pull request (#61) that aims to improve robustness against telegram-cli media problems. To try this:

1. Clone master of the fork https://github.com/pdonadeo/telegram-history-dump
2. Set a media_timeout in the telegram-history-dump settings

[CodingFree]

Thanks and sorry for the late answer, I was able to download some files, but I think that the error was related to this, which was crashing the dumper and sending a SIGNAL to telegram-cli. It's happening also with pdonadeo's forki:

E, [2017-01-13T09:39:53.965329 #6565] ERROR -- : Failed to download media file: no implicit conversion of nil into String

*** 1484296793.926910 result for query #6375006187094277120. Size 12 bytes *** 1484296793.926940 in_ptr = 0x40c3b44, end_ptr = 0x40c3b50 *** 1484296793.926992 pts = 1969407, pts_count = 0 *** 1484296793.927022 Ok update. pts = 1969407 *** 1484296793.933575 try read: fd = 7 *** 1484296793.933687 Received 9824 bytes from 7 *** 1484296793.947587 Read from incoming connection [98%Down]> SIGNAL received

[tvdstaaij]

The order of events is this: telegram-cli crashes with SIGNAL received -> telegram-history-dump expects a response string from the socket but gets none, and crashes too. It is hard to work around telegram-cli bugs that cause crashes (they should really be fixed in telegram-cli, but development seems rather dead). pdonadeo's changes help in some cases but cannot do anything about crashes. The best approach for now is to avoid dumping dialogs (or limiting their history) that cause crashes in telegram-cli. Or try to debug the underlying problem in telegram-cli.

I do have an idea that might be able to give the dumping process some crash resistance, see my reply to another user:

As for your issue, the problem is that telegram-cli can be rather unstable, especially when media downloading is involved, and simply crashes in some situations. Unfortunately my script can't prevent telegram-cli from crashing. I'm currently playing with some ideas for a v3 of this script that would automatically run telegram-cli in the background. Then if it crashes, it could also be restarted and proceed from the next chunk.

But this would be a rather major change and I haven't found time to work on it yet.