Infeasible
Status Update
No update yet.
Comments
ph...@gmail.com
Agreed, you can download photos via the Google Drive API but this hasn't been incorporated into the Photos API yet...
ra...@google.com
ra...@google.com
There's already an issue tracking the missing EXIF data here: https://issuetracker.google.com/111228390
Regarding the file at original quality - this is something that's on our list and will be addressed soon, please stay tuned. I'll update this bug once we have an update to share.
Regarding the file at original quality - this is something that's on our list and will be addressed soon, please stay tuned. I'll update this bug once we have an update to share.
ph...@gmail.com
We have just released a new version of the Google Photos Library API that supports now this feature.
You can now use the "d" base URL parameter to download the original photo. See the base URL parameter guide for more details:https://developers.google.com/photos/library/guides/access-media-items#image-base-urls
Thanks for your patience!
See our release notes for further detail:https://developers.google.com/photos/library/support/release-notes#2018-07-31
You can now use the "d" base URL parameter to download the original photo. See the base URL parameter guide for more details:
Thanks for your patience!
See our release notes for further detail:
ra...@google.com
I've been testing downloading images using the "d" parameter, but the files returned are not the original files that were uploaded. The release note above reads "d download parameter, to download the original image". The link to the developer documentation doesn't say that the "original" image will be downloaded. Please can you confirm if the d parameter should download the original image that was uploaded to the api, or if this behavior has since changed.
ph...@gmail.com
I've tested this again, and the file download is a mutated version of the file uploaded to Photos. If I use the web browser and go to photos.google.com , when I "Download" a photo it is byte-for-byte identical to the file I uploaded. If I use the API and attempt to get a copy, with the included "d" base URL, the file is mutated. Both some metadata is missing, as well the photo itself is modified (doing a pixel-for-pixel comparison shows subtle differences).
ra...@google.com
I can confirm this is still broken and using the 'd' parameter does not return the original photo.
sa...@google.com
ho...@herddogg.com
This is still an issue
sa...@google.com
How is it marked as fixed? =d parameter still doesn't work
to...@gmail.com
I heard (at Pixel phone help community) that the newly released Pixel4a has the similar problem.
Is it better to open as a new issue post or is that OK to re-open the issue here?
Is it better to open as a new issue post or is that OK to re-open the issue here?
ja...@googlemail.com
Yes - and the Pixel 5. What the hell Google. What the hell.
gd...@simbex.com
Bummer ... looks like I'm returning the Pixel 4a we just got. Was hoping to standardize our product on this device ... back to my search.
ki...@gmail.com
To save everyone here some searching time, I can confirm the One Plus 6 and One Plus 7 (and their pro variants) will work with LE Coded PHY advertising scanning. I've gotten better luck with connecting LE Coded PHY using the One Plus 7.
Good luck!
Good luck!
lu...@gmail.com
OnePlus 8 (and the T and Pro variants) also works!
es...@gmail.com
Pixel 6 Have same problem
pa...@nearfaces.com
Is the Pixel 6 going to be fixed so LE Coded PHY advertising scanning works ?
pa...@nearfaces.com
This is surely a software bug in Googles implementation as the BLE HW IP is probably a bought in HW IP and not developed by Google.
If not a great advert if OnePlus6,7,8 all are OK and the pixel 6 isn't.
If not a great advert if OnePlus6,7,8 all are OK and the pixel 6 isn't.
es...@gmail.com
I think I found root of problem. I report issues
es...@gmail.com
*Maybe in OnePlus6,7,8 BLE controller always...
pa...@nearfaces.com
Yes this is the place to look (227887174 I mean).
es...@gmail.com
So I replace with magisk bt library with patched code. I just enable scan on 1M and coded and now I can see Coded phy on my Pixel 6. So yes it's definitely bug in btm_send_hci_set_scan_params as I say in 227887174
pa...@nearfaces.com
Cool - good progress :-)
pa...@nearfaces.com
What happens next ?
"So I replace with magisk bt library with patched code. I just enable scan on 1M and coded and now I can see Coded phy on my Pixel 6. So yes it's definitely bug in btm_send_hci_set_scan_params as I say in 227887174" - when does this get implemented and ideally push out in the next pixel update ?
Not that I am impatient ;-) .....
"So I replace with magisk bt library with patched code. I just enable scan on 1M and coded and now I can see Coded phy on my Pixel 6. So yes it's definitely bug in btm_send_hci_set_scan_params as I say in 227887174" - when does this get implemented and ideally push out in the next pixel update ?
Not that I am impatient ;-) .....
es...@gmail.com
Oh no. This patch is still not accepted by google. And what I do is 'hack' to confirm the right place of the bug. First we need to wait for google to accept a patch(maybe with some modification). And only after that we can expect to include to next update
pa...@nearfaces.com
Is there any updates with this bug ? I see on the google bug tracking number 227887174, that there is a restricted comment. Is there any information that can be shared publicly ?
ja...@googlemail.com
Pixel 7 still has this problem
pa...@nearfaces.com
I was hoping as the Pixel 7 has a different IP for the wireless comms that might have allowed this to be fixed.
It seems it can be done (even with other pixel phones) - see comment 21 above.
Why is this bug marked with status "Won't fix (Infeasible)" ? A little more info from Google wouldn't go amiss...
It seems it can be done (even with other pixel phones) - see comment 21 above.
Why is this bug marked with status "Won't fix (Infeasible)" ? A little more info from Google wouldn't go amiss...
pa...@nearfaces.com
Samsung and OnePlus phones support this feature in the BLE spec. !
ja...@gmail.com
Bump. Developers still want this google...
Description
Both claim to support Bluetooth LE PHY Coded (BluetoothAdapter#isCodedPhySupported).
I use nRF Connect for Android for testing. The app can only scan for packets when Primary PHY is PHY LE 1M. If both primary and secondary PHY are set to Coded, those phones don't find anything. However, OnePlus 6 does return a result after ~10 seconds, which implicate it's a controller issue. The need of using1M PHY for advertising long range packets makes the whole long range useless.
Tested with S=8. I can see the packets using Ellisys Bluetooth Analyzer. When primary advertising is sent over PHY Coded those 2 phones don't return any device.
This can be also tested with 2 phones and nRF Connect installed on both. Use one to advertise and one for scanning. If the advertising is set to use Coded PHY for both primary and secondary PHY the packets are seen on Ellisys sniffer, but not on the phone.
Also, when BluetoothLeScanner is using ScanSettings.Builder#setPhy(BluetoothDevice.PHY_LE_CODED), the scanner returns also only 1M packets and no error is thrown that coded phy would not be supported. In this case, the expected result would at least be no devices reported.