Describe the bug
See gphotosuploader/gphotos-uploader-cli#158

Describe the bug
Go Report Card score is 51% on golint. We should improve it.

The GetUploadToken method should not be exposed outside this module.

This is a breaking change with no backwards compatibility A new v2 version should be published.

When more than one worker is calling GetOrCreateAlbumByName() a race condition may appear. While a thread is looking for an album, another thread coulbe creating it. The first thread ends without finding it and try to create it, but the second thread already created it.

Google Photos doesn't disallow having several albums with the same name, so this needs to be handled in our side.

A sync.RWLock could be a good idea.

See gphotosuploader/gphotos-uploader-cli#135 for more details. Thanks to @mjhatcher

We have two different modules sharing the same gphotos package name. That's a bit confusing, so we should address it differently to use different packages.

This is a breaking change and should be part of new v2 release

Is there a way - like with Google Photos uploader CLI for uploads - to completely download/mirror one's Google Photos photos and videos?

Thanks!

gphotos-uploader-cli does not respect Google Photos quote limit because google-photos-api-client-go album Repository.Create does not return anything useful in the error message that would indicate that the limit has been reached.
All it returns is

(*url.Error)(0xc00072cc30)(Post "https://photoslibrary.googleapis.com/v1/albums?alt=json": POST https://photoslibrary.googleapis.com/v1/albums?alt=json giving up after 5 attempt(s))

Informing the user there has been 5 attempts, but the HTTP code there is no where to be found.
To solve this issue in gphotos-uploader-cli one can attempt to write something ugly like this

album, err := service.Create(ctx, title)
	if err != nil {
		if urlerr, ok := err.(*url.Error); ok {
			if  strings.ToUpper(urlerr.Op) == http.MethodPost && urlerr.URL == "https://photoslibrary.googleapis.com/v1/albums?alt=json" {
				wrappedErr := urlerr.Unwrap()
				if strings.HasPrefix(wrappedErr.Error(), "POST https://photoslibrary.googleapis.com/v1/albums?alt=json giving up after ") {
					return "", fmt.Errorf("quota limit reached for %w, check https://console.cloud.google.com/apis/api/photoslibrary.googleapis.com/quotas", err)
				}
			}
		}
		return "", err
	}

But since it does not know what the original problem was, it could mislead. So essentially there is no way to fix it in gphotos-uploader-cli It has to be fixed here, in this project.

Describe the bug
Currently it seems that MediaItems.ListByAlbums only returns the first page of results. For albums with more photos, only the latest 25 are returned in the []mediaItems slice.

To Reproduce
Steps to reproduce the behavior:

        gpc, err := gphotos.NewClient(client)
        ta, err := gpc.Albums.GetById(ctx, "<AlbumId>")
        if err != nil {
                log.Fatal(err)
        }
        taid := ta.ID
        log.Println("Album Count is: " + ta.MediaItemsCount)
        mic,err := strconv.Atoi(ta.MediaItemsCount)
        if err != nil {
                log.Fatal(err)
        }
        cmi := rand.Intn(mic - 1)
        log.Println("Chosen Media Index is: " + strconv.Itoa(cmi))

        am, err := gpc.MediaItems.ListByAlbum(ctx, taid)
        log.Println("Number of Media Items Returned is: " + strconv.Itoa(len(am)))

Output:

2022/01/04 09:36:45 Album Count is: 11558
2022/01/04 09:36:45 Chosen Media Index is: 11346
2022/01/04 09:36:46 Number of Media Items Returned is: 25

Expected behavior
Paging should be supported so that all media items can be retrieved.

Additional context
I'm writing a go program that will randomly choose a photo from a given (large) album.

See issue on gphotos-uploader-cli: gphotosuploader/gphotos-uploader-cli#127

See gphotosuploader/gphotos-uploader-cli#110

Hi ,

I need some help from you guys, probably this is not a bug and and I'm doing something wrong, but I'm getting always bad request when trying to upload an photo.

I've investigate a bit the code and something raise my attention. In bellow function we are putting nil on body request, is this the expected value or should it be the return of item.Open() ?

func (u BasicUploader) prepareUploadRequest(item uploader.UploadItem) (*http.Request, error) {
	_, size, err := item.Open()
	if err != nil {
		return nil, err
	}

	req, err := http.NewRequest("POST", u.url, nil)

Describe the bug

The upload file is throwing an bad request (http 400)

To Reproduce

Sample code for basic upload:

...

srv, err := gphotos.NewClient(client)

...

s, err := srv.Uploader.UploadFile(ctx, "img1.jpg")

I'm receiving the following error:

got 400 Bad Request: {
"code": 3,
"message": "Payload must not be empty"
}

Expected behavior

Get the upload token if the photo was successful uploaded.

Is your feature request related to a problem? Please describe.
This package writes a log line to stdErr for each request. There is not way to disable it.

Describe the solution you'd like
Disable DEBUG log by default.

Describe alternatives you've considered
Add a new option to enable/disable this DEBUG log

We should follow Google Developer Guide to implement retry policy when calling external API.

Now we are using a very simple retry mechanism: 3 retries with fixed duration between them.

Hello,

could you please provide an analogue of PhotosLibraryAlbumsRepository.ListAll but without setting "excludeNonAppCreatedData" parameter to "true"?

Thank you!

v3.0.0 is almost ready

We're almost ready to release a new major version v3.x. 🥳

There are plenty of changes on it, most of them are non-backwards compatible, and we would like to let you provide feedback before releasing the final version. 👉🏼 Take a look to the CHANGELOG on the 3.x branch. 👈🏼

Please review the latest v3.x tag and use it in your code. 🙏🏼

// New module path
import gphotos "github.com/gphotosuploader/google-photos-api-client-go/v3"

Feel free to add new issues to address bugs or feature requests and share the link here.

Do you have any feedback?

We are relying in status message response, we should use code instead as it's suggested here.

Describe the bug
Take a look to gphotosuploader/gphotos-uploader-cli#398

To Reproduce
Steps to reproduce the behavior:

1. Upload an object
2. Go to Google Photos UI and show the object's metadata
3. See filename field

Expected behavior
The filename field should be set to the local filename when the file was uploaded, the upload date is shown instead.

Describe the bug
Why PhotosLibraryAlbumsRepository ListAll function use excludeNonAppCreatedData ?

Expected behavior
Maybe use ListAll to get all albums and another function like ListNotAppCreateAlbum to get albums that not created by this app.
Or pass option to ListAll function, let user can enable the exclude option or not.

The method AlbumByName is getting Google Photos album list and checking if there is an album with the specified name. For this purpose is using album.list, but based on the documentation it's only checking first 20 albums, so It's possible that some albums are not checked, causing albums with the same name are created or an error is thrown.

Various places in https://github.com/gphotosuploader/google-photos-api-client-go/blob/master/lib-gphotos/uploads.go call .Do to send a request. They check the err returned but that err is unset if the http request executes correctly but returns a non-200 status.

Something needs to also check res.StatusCode

https://golang.org/pkg/net/http/#Response

Otherwise you get mysterious failures with no useful error output. In my case it's an authentication error.

Sorry not in a good position to supply a patch but it seems like it should be fairly trivial.

Is your feature request related to a problem? Please describe.
The v2.x of the module was offering an Album's cache to reduce the number of calls to the Google Photos API.

Example: When you were trying to GetByTitle several times, we were expecting to reuse previous List calls to eventually get the album without sending a new request.

Over the time, the Album's cache has become ineffective, and it's strongly recommend to implement this kind of cache on the client side. The client has more context to set what to cache and how long. The gphotos-uploader-cli is already implementing it this way, and reducing the amount of request by 20x.

Describe the solution you'd like
Remove the CachedAlbumsService and create a raw service wrapping the Google Photos client.

The contract should be kept, so backwards compatibility is expected.

Describe alternatives you've considered
Offer both, the CachedAlbumsService and the new one.

Additional context
Given the change, a major version should be published after this.

See gphotosuploader/gphotos-uploader-cli#129

Describe the bug
The bug was reported on gphotosuploader/gphotos-uploader-cli#262. In some cases (I don't know when) Google Photos response include no MediaItem. The code panics when it tries to access to a nil MediaItem.

To Reproduce
When creating a media item the lines:

       mediaItemsResult := make([]MediaItem, len(result.NewMediaItemResults))
	for i, res := range result.NewMediaItemResults {
		m := res.MediaItem
		mediaItemsResult[i] = r.convertPhotosLibraryMediaItemToMediaItem(m)
	}

If result.NewMediaItemResults has some MediaItem pointing to nil, the code fails when it tries to access to it.

Expected behavior
It should not panic.

Additional context
The Google Photos API documentation is not saying anything about MediaItem pointing to nil on successful responses..