server pickle related error

[yajrendrag]

just starting with this.. installed per instructions here: https://www.home-assistant.io/docs/asterisk_mbox/ so haven't even installed the client on hass yet.

seems like something related to the cache file. i set the cache_file to a fully qualified path to a file owned by asterisk. that file is empty. and when i start the server from the shell, i get the following errors:

  File "/usr/local/bin/asterisk-mbox-server", line 9, in <module>
    load_entry_point('asterisk-mbox-server==0.5.2', 'console_scripts', 'asterisk-mbox-server')()
  File "/usr/local/lib/python3.4/dist-packages/asterisk_mbox_server/__init__.py", line 300, in main
    AsteriskMboxServer().loop()
  File "/usr/local/lib/python3.4/dist-packages/asterisk_mbox_server/__init__.py", line 170, in __init__
    {'GOOGLE_KEY': self._opts['google_key']})
  File "/usr/local/lib/python3.4/dist-packages/asterisk_mbox_server/mbox.py", line 39, in __init__
    self.cache = pickle.load(infile)
EOFError: Ran out of input

if instead of the file being empty, it's set to some text - i get this error instead:

  File "/usr/local/bin/asterisk-mbox-server", line 9, in <module>
    load_entry_point('asterisk-mbox-server==0.5.2', 'console_scripts', 'asterisk-mbox-server')()
  File "/usr/local/lib/python3.4/dist-packages/asterisk_mbox_server/__init__.py", line 300, in main
    AsteriskMboxServer().loop()
  File "/usr/local/lib/python3.4/dist-packages/asterisk_mbox_server/__init__.py", line 170, in __init__
    {'GOOGLE_KEY': self._opts['google_key']})
  File "/usr/local/lib/python3.4/dist-packages/asterisk_mbox_server/mbox.py", line 39, in __init__
    self.cache = pickle.load(infile)
_pickle.UnpicklingError: invalid load key, 'H'.

"H" happens to be the first character of the file.

i'm at a loss on what to look for. i already had an API key to google's speech recognition service (it's the older free one for personal/developers - the key is only 39 characters - vs the newer cloud speech api. not sure if that matters).

there are some existing voice mails in my asterisk voice mail account.

any suggestion/thought as to what i may be doing wrong?

system is python 3.4.2, debian jessie.

[yajrendrag]

this appears to be a permissions issue. in looking through the code, it seems there's a default cache file if none is specified, & after removing the cache_file line from the config, i got a different error related to permissions. once i started the server from a directory that the asterisk user could write to, i was able to move past that issue.

Then generated another errror:

Traceback (most recent call last):
  File "/usr/local/bin/asterisk-mbox-server", line 9, in <module>
    load_entry_point('asterisk-mbox-server==0.5.2', 'console_scripts', 'asterisk-mbox-server')()
  File "/usr/local/lib/python3.4/dist-packages/asterisk_mbox_server/__init__.py", line 300, in main
    AsteriskMboxServer().loop()
  File "/usr/local/lib/python3.4/dist-packages/asterisk_mbox_server/__init__.py", line 170, in __init__
    {'GOOGLE_KEY': self._opts['google_key']})
  File "/usr/local/lib/python3.4/dist-packages/asterisk_mbox_server/mbox.py", line 47, in __init__
    self.inot.add_watch(directory.encode('utf-8'))
  File "/usr/local/lib/python3.4/dist-packages/inotify/adapters.py", line 93, in add_watch
    path_bytes = path_unicode.encode('utf8')
AttributeError: 'bytes' object has no attribute 'encode'
DEBUG:inotify.adapters:Cleaning-up inotify.

[yajrendrag]

this appears to be related to debian/ubuntu (have tried several OS variants) or maybe the voicemail app isn't the original. Same failure as above - bytes object has no attribute 'encode'. i tried another asterisk distribution that runs on Centos 7 and asterisk-mbox-server runs fine on that distro.

EDIT - actually there's no difference - once i got voicemail on the centos based system, it generates the same error as above. I've tried this with python 3.4.2, 3.5.3 and 3.6.5 based systems. always end up here. wondering if there's a fix.

[scottbender]

Same issue on Debian Stretch. You can bypass the issue by editing the adapters.py file in your error message and change line 93 to:

path_bytes = path_unicode

I don't understand why this works, but it got me past this error. Now I'm stuck on the hass module authenticating to the service.

[scottbender]

Actually, after reading what I did, its probably better to edit mbox.py instead of adapters.py(which is the inotify package)

Line 47 should read "self.inot.add_watch(directory)". I think the error is due to encoding to utf-8 twice.

[scottbender]

Next issue. Currently HASS will force install of asterisk-mbox version 0.4.0, but authentication fails because the server is at version 0.5.0. :/

I just need to figure out how to submit patches.

[yajrendrag]

thanks! your fix on the asterisk side worked for me, and seeing same version mismatch error on the client. Would trying to upgrade asterisk_mbox through pip on HASS work?

[scottbender]

I tried that. no luck... I had to edit utils.py to say version 0.5.0 (instead of 0.4.0). I have a venv set up, so my path was /opt/homeassistant/lib/python3.5/site-packages/asterisk_mbox/utils.py Mine is now working. Enjoy :)

[yajrendrag]

hmm, odd, i did the pip3 install --upgrade and my utils.py does show the correct version but the message exchange between client and server is still showing a version mismatch.. anyway, thanks for your help getting this far. will try removing the asterisk_mbox from HASS completely and re-adding again.

EDIT - evidently, every time HASS starts it updates the mailbox component to 0.4.0, so doing the pip3 install --upgrade doesn't help. but editing the utils.py in the installed 0.4.0 version to say 0.5.0 instead of 0.4.0 does work... until the patch below comes through

[PhracturedBlue]

I had subitted the bump to 0.5 in home-assitant here: https://github.com/home-assistant/home-assistant/pull/11043 But it was part of a bigger patch to enable display of the CDR which was rejected. I need to rework that patch, but I can submit a patch to bump the version to 0.5.0 at least

[scottbender]

Perfect. I'll hold off. I was going to suggest >=0.4.0 instead of ==0.5.0 so a HASS upgrade wont break when the server side is still at 0.4.0.

[bkbilly]

Hello, I think that all these issues will be solved with the new pull Request I did here #6. Hope this helps.