jmrodri / sm-photo-tool

When I try to list my galleries, which contain non standard 'ascii'
characters (german umlauts: äöüß and so on) I get the following
message:

Traceback (most recent call last):
File "/usr/local/bin/sm_photo_tool.py", line 746, in
main()
File "/usr/local/bin/sm_photo_tool.py", line 734, in main
listgalleries(Options(argv[3:]))
File "/usr/local/bin/sm_photo_tool.py", line 709, in listgalleries
smugmug.list_galleries(opts, rest)
File "/usr/local/bin/sm_photo_tool.py", line 376, in list_galleries
message(opts, "%9d: %s\n" % (alb['id'], alb['Title']))
File "/usr/local/bin/sm_photo_tool.py", line 77, in message
stdout.write(string)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
28-29: ordinal not in range(128)

I can change the line 77 to
stdout.write(string.encode("utf-8"))
and it works, but the character is still not displayed in the correct way,
like "ä" for "ä" (terminal encoding is utf-8). Maybe there is already
before a conversion problem.
I'm running Ubuntu 8.10 amd64.

Best,

André

I'm having an issue using this on Fedora Core 5. It can create the albums
and it says that it is uploading the files, but the album in smugmug
remains empty.

Someone on digitalgrin.com had this same problem. His problem was fixed by
a version from David. I tried this same file and it did not work for me.

Program Output

[root@wdhl002 The Valley]# sm-photo-tool create test *.JPG ./IMG_0539.JPG...[OK] 495576 bytes 4 seconds 121KB/sec ETA 2:13 ./IMG_4749.JPG...[OK] 609322 bytes 7 seconds 79KB/sec ETA 3:17 ./IMG_5128.JPG...[OK] 556810 bytes 6 seconds 91KB/sec ETA 2:44

Thanks,
Spence

spence at digis.net

Change sm_wrapper.py to use the JSON api instead of the XMLRPC api. Also consider using PUT for uploading images instead of base64 encoding them.

There is logic in the code for looking up the smugmug "internal" categoryid
number and subcategoryid number that is flawed.

line 236:

if re.match("\d+$",category_string):
return string.atoi(category_string)

and line 247:

if re.match("\d+$",subcategory_string):
return string.atoi(subcategory_string)

If the passed in "category" or "categoryid" is a number, the code assumes
(never assume!!!!) that the user must be specifying a smugmug internal categoryid/subcategoryid number, and it does not do the proper
lookup/mapping. (In my case, I have custom categories for 'Year' and
custom subcategories for 'Month', all specified as digits!!!)

My suggestion? Have a different parameter for when one already knows that
info, and doesn't want to do the lookup.

sm-photo-tool update seems to always restart the uploading instead of resuming where it left off. Seems to be ignoring the entries in SMUGMUG_INFO

RPM sample output:
Preparing... ########################################### [100%]
1:spacewalk-java-lib ########################################### [ 25%] 2:spacewalk-java-config ########################################### [ 50%] 3:spacewalk-java ########################################### [ 75%] 4:spacewalk-taskomatic ########################################### [100%]

sm-photo-tool current output:
./IMG_5328_DxO_raw.jpg...[OK] 3452528 bytes 14 seconds 244KB/sec ETA 319:37 ./IMG_5340_DxO_raw.jpg...[OK] 16178227 bytes 66 seconds 241KB/sec ETA 322:20 ./IMG_5342_DxO_raw.jpg...[OK] 17569128 bytes 89 seconds 195KB/sec ETA 397:18 ./IMG_5343_DxO_raw.jpg...[OK] 16193504 bytes 53 seconds 304KB/sec ETA 253:49 ./IMG_5349_DxO_raw.jpg...[OK] 8921949 bytes 35 seconds 252KB/sec ETA 305:20 ./IMG_5351_DxO_raw.jpg...[OK] 18029918 bytes 86 seconds 207KB/sec ETA 370:34 ./IMG_5353_DxO_raw.jpg...[OK] 19482741 bytes 72 seconds 266KB/sec ETA 286:59 ./IMG_5354_DxO_raw.jpg...[OK] 17545485 bytes 81 seconds 216KB/sec ETA 352:35 ./IMG_5356_DxO_raw.jpg...[OK] 19647791 bytes 89 seconds 218KB/sec ETA 347:04