Don't raise exception when share entries don't exist

[crackfoo]

I often see error about collect minutes:

processname:scheduler groupname:scheduler pid:31600 channel:stdout
2015-02-18 10:36:35,015 [simplecoin] [INFO]: Processing key min_dup_sha256_1424273700
READY
RESULT 1168
processname:scheduler groupname:scheduler pid:31600 channel:stdout
2015-02-18 10:36:35,015 [simplecoin] [ERROR]: Unhandled exception in collect_minutes
Traceback (most recent call last):
  File "/home/crackers/www/pools/simple/simplecoin_multi/simplecoin/scheduler.py", line 51, in crontab
    res = func(*args, **kwargs)
  File "/home/crackers/www/pools/simple/simplecoin_multi/simplecoin/scheduler.py", line 1085, in collect_minutes
    redis_conn.rename(key, "processing_shares")
  File "/home/crackers/.virtualenvs/scm/local/lib/python2.7/site-packages/redis/client.py", line 1011, in rename
    return self.execute_command('RENAME', src, dst)
  File "/home/crackers/.virtualenvs/scm/local/lib/python2.7/site-packages/redis/client.py", line 565, in execute_command
    return self.parse_response(connection, command_name, **options)
  File "/home/crackers/.virtualenvs/scm/local/lib/python2.7/site-packages/redis/client.py", line 577, in parse_response
    response = connection.read_response()
  File "/home/crackers/.virtualenvs/scm/local/lib/python2.7/site-packages/redis/connection.py", line 574, in read_response
    raise response
ResponseError: no such key
READY
RESULT 230
processname:scheduler groupname:scheduler pid:31600 channel:stdout
2015-02-18 10:36:35,016 [apscheduler.scheduler] [INFO]: Job "collect_minutes (trigger: cron[second='35'], next run at: 2015-02-18 10:37:35)" executed successfully
READY

Does this simply clear itself up?

[crackfoo]

There error shows up every 2nd occurrence/run of collect_minutes...

[ericecook]

This is expected behavior, although it probably should be catching that error and logging it to debug.

Basically powerpool is putting share & ppagent data into redis with a specific key prefix. SCM looks for keys with that prefix to pulls that data out, and then deletes that key. This error is the result of no keys matching that prefix being available. This is intended, SCM should check redis about 2x more frequently than Powerpool actually stores data - this helps keep things up to date