Re: SubSurface Mobile and OTG
This does work for some divecomputers, depending on the ftdi chip that is used on the cable. We also have some trouble with Android OS as some newer Android versions prevent us from accessing the USB devices. What versions of DC, cable (the serial chip), phone and Android you are using? (I have used OTG on Nexus 7 tablet and Suunto Vyper Air DC successfully, don't remember the Android version on the tablet.) On Wed, May 23, 2018 at 8:15 AM, Thomas Fängewrote: > Hi! > > First, thanks all for you effort and the great and useful application! > > I'm connecting my dive computer to my Linux laptop, and that works perfect. > But, wouldn't it be possible to do that on the SubSurface Mobile (Android) > app too? > > I have a "watertight" Sony phone, and I use a USB On-The-Go (OTG) cable to > use e.g. a mouse or external keyboard, so should it not then be possible to > use USB-communication from the SubSurface app too, instead of only a > Bluetooth connection? This would enable me to only bring the phone while > travelling, even on the boat or shore and download my dives, getting the > current position etc. without worrying if the phone gets wet or not. > > Today, when I connect the dive computer to the phone with the OTG cable, I > can see on the leds on the interface cable that the connection is made to > the phone, but that interface (USB) never turns up as an option in the > SubSurface dive computer menu - only Bluetooth is available there. > > Best regards, > Thomas > > > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Hashing videos
Hi Lubomir and Willem, On Dienstag, 22. Mai 2018 23:06:03 CEST Lubomir I. Ivanov wrote: > i was thinking about running hashes on the thumbnails but that has a > couple of problems: I think generating hashes of thumbnails is out of the question. Not only, as you note, may Qt's scaling algorithm change; extracting thumbnails from videos is at the moment not even supported. You can have different streams, embedded thumbnail(s), and other complexities. This is all very unstable. > i guess the biggest question here is what are the hashes used for? > if they are used to skip the generation of thumbnails for already > existing media, then the above proposal is completely invalid. Indeed, let's wait for Robert's assessment. > > Or perhaps even remove the hashes? I found three users: > > 1) In git storage. This is unsupported afaik. > > 2) The "Find moved images" functionality. Perhaps searching for (case- > > insensitive?) filenames is enough? Or perhaps match by metadata? > > 3) In current head it is also used for the thumbnail files, but this > > could be changed before doing the next release. > > something like hashing the date/time + metadata is a good option too i > guess. depends on what we need a hash for. We wouldn't even have to hash that, as we just store it unhashed. One scheme that came to mind (supposing the only point of the hashes is to find moved pictures): We consider two pictures as equivalent if 1) They have the same filename (modulo path and case) 2) They have the same length 3) They have the same meta-data in the case of JPEG Finding two different pictures fulfilling 1-3 must be very bad luck. We currently don't store file-length, but that can be trivially rectified when opening an old log. It would not find renamed pictures, but that also sounds like a case of "tough luck". Berthold ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
SubSurface Mobile and OTG
Hi! First, thanks all for you effort and the great and useful application! I'm connecting my dive computer to my Linux laptop, and that works perfect. But, wouldn't it be possible to do that on the SubSurface Mobile (Android) app too? I have a "watertight" Sony phone, and I use a USB On-The-Go (OTG) cable to use e.g. a mouse or external keyboard, so should it not then be possible to use USB-communication from the SubSurface app too, instead of only a Bluetooth connection? This would enable me to only bring the phone while travelling, even on the boat or shore and download my dives, getting the current position etc. without worrying if the phone gets wet or not. Today, when I connect the dive computer to the phone with the OTG cable, I can see on the leds on the interface cable that the connection is made to the phone, but that interface (USB) never turns up as an option in the SubSurface dive computer menu - only Bluetooth is available there. Best regards, Thomas ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Hashing videos
hello, i believe Robert should comment on this as he originally wrote the first implementation of the profile photos. (CC). On 22 May 2018 at 23:45, Berthold Stoegerwrote: > Dear all, > > I'm currently implementing addition of videos to the dive photos. This happens > to be dog-slow, because we calculate hashes of the file contents. As you can > imagine, addition of multiple videos with a few GB each is a major CPU hog. > Granted, the UI stays responsive, since this is done in background threads. > Nevertheless, it gives a bad impression if the CPUs run at 100% for a few > minutes. > > What are we supposed to do? Hash only the first MB? That would unfortunately > not be backwards-compatible. Do different things for images and videos? Sounds > hard to get right. > i was thinking about running hashes on the thumbnails but that has a couple of problems: 1) if Qt changes the backend of the code we use for thumbnail generation the hashes would stop matching 2) thumbnail generation for videos would need to happen not for the first frame but rather for an arbitrary point of the video timeline - e.g. thumbnail at 30% length. (that's actually a good generic way of doing it, instead of using always the first frame) but if two thumbnails for two videos happen to have exactly the same frame at those 30% of the length (e.g. consider a black screen transition), we risk generating the same hash for two different videos for the same frame. that on the other hand might not be ever possible for compressed video, as the compression adds noise which would essentially generate thumbnails with slightly different bytes, unless it's uncompressed RAW video in which case the thumbnails would match perfectly and therefore the hashes too. i would still consider this as an option if we really need hashes and we want them to be fast. i guess the biggest question here is what are the hashes used for? if they are used to skip the generation of thumbnails for already existing media, then the above proposal is completely invalid. > Or perhaps even remove the hashes? I found three users: > 1) In git storage. This is unsupported afaik. > 2) The "Find moved images" functionality. Perhaps searching for (case- > insensitive?) filenames is enough? Or perhaps match by metadata? > 3) In current head it is also used for the thumbnail files, but this could be > changed before doing the next release. > something like hashing the date/time + metadata is a good option too i guess. depends on what we need a hash for. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Hashing videos
Dear all, I'm currently implementing addition of videos to the dive photos. This happens to be dog-slow, because we calculate hashes of the file contents. As you can imagine, addition of multiple videos with a few GB each is a major CPU hog. Granted, the UI stays responsive, since this is done in background threads. Nevertheless, it gives a bad impression if the CPUs run at 100% for a few minutes. What are we supposed to do? Hash only the first MB? That would unfortunately not be backwards-compatible. Do different things for images and videos? Sounds hard to get right. Or perhaps even remove the hashes? I found three users: 1) In git storage. This is unsupported afaik. 2) The "Find moved images" functionality. Perhaps searching for (case- insensitive?) filenames is enough? Or perhaps match by metadata? 3) In current head it is also used for the thumbnail files, but this could be changed before doing the next release. Ideas? Berthold ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface