I'm playing arround a little bit with Decrypting whatasapp.
When I decrypt and open the sqlite3 that can be found /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/Databases/msgstore.db.crypt15 I only see messages until last night. It seems that whatsapp is storing the messages until the night backup in other place. When the night backup occurs the /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/Databases/msgstore.db.crypt15 is updated. When I play with this file during the day it's never updated in my phone but whatsapp messages are coming in normally.
If having a look at the file:
actual date: 20230204 18:37:45
file created: 20230204 02:02:39
file modifyed:20230204 02:01:47
Related
We are in Australia East.
We have an event hub with events coming through from an application. On Friday 19th March morning I created a Stream Analytics job, to try and read one of the event streams. This worked successfully on the Event Hub and returned results in the "Input preview" window when setting this up. This seems to match the timings on the message below (we are about 12 hours in front of UTC).
However by Friday afternoon, it started failing with one of the error messages "InternalServerError" or "No such host is known". I was working through the drop down boxes available when creating a new input after selecting "Select Event Hub from your subscriptions", so I know I haven't got anything wrong in the setup.
When trying to submit a support request, we get this slightly cryptic message:
The link doesn't work, it claims Stream Analytics is not supported in Resource Health, even though it is. Does this mean "It's down sorry, we are working on it" (as in actually working on it), or is it a canned response and we should escalate it?
Or is anyone else having trouble creating Stream Analytics Jobs and we are suffering an outage? The Azure Status monitor shows they are in good health.
Looks like this was a permission error. I needed to go into the IAM of the Event Hub and set the Stream Analytics Job up with Reader permissions. For some reason, this wasn't automatically added when setting up the Stream Analytics Job, as I thought it would be.
Once the permission was set, the job started successfully.
We've recently started adding programmed radio to our existing SMAPI implementation. I've followed the Sonos Developer documentation and (eventually) got it working as expected. I'm just seeking for some clarification around the 'auto updating' based on the 'queueVersion' value.
Our schedules which are feeding the programmed radio can change from time to time. These changes should be reflected on the Sonos Players as soon as possible. For what I understand this should be possible by modifying the queueVersion property in both GET /context, GET /itemWindow and GET /version.
Looking at the GET /version documentation I see that Players "[...] are responsible for periodically polling this [QueueVersion] value to detect changes in the cloud queue track list, [...]".
I've monitored our API logs for about 15 minutes in which I would expect at least a GET /version request, but none showed up. The only calls I'm seeing are POST /timePlayed.
Can anyone (from the Sonos team perhaps?) clarify what this interval is set to, or how it can be controlled?
Given that you aren't seeing GET /version requests, there may be an error in your configuration.
The player sends a GET /version request every 5 minutes when paused and every 10 minutes when playing. This is by design, not depending on any setting that you can control. However, players fetch new tracks as needed using GET /itemWindow. The player requires a version in your response, so it doesn't send a GET /version request in this case. After the player gets a new item window, it resets the polling interval to another 10 minutes.
See the Play audio (cloud queue) page for details.
Using a video element on a subscriber / viewer for a live stream, is it possible to get the running stream time? I know that ontimeupdate will give the time (in seconds) at which playback started, but I need the live streams time; the start of publishing instead. The bottom line is that I'd like to know how close to in-sync my publisher and subscriber are.
In my scenario a live publisher has been publishing for 10 minutes and a subscriber connects and starts playing; the subscribers ontimeupdate will yield a value around 0.1 or so, which would be 600 seconds behind in my case.
I have joined a bot in a group to archive the messages. I'm coding a php code for archiving, till this get complete, I manually getupdates from the browser. and save the results in a text file. and frequently I use offset to get newer msgs. but next time when I getupdates after offset (for example one after that) I see that I have a jump! for example if the last id was 1500, after getupdate I see 1553 or 1540, and I donn't see the msgs in the gap. anyone can help me,please?
I may be because old updates are deleted if not requested in a period of time (about 24 hours).
From https://core.telegram.org/bots/api#getting-updates:
Incoming updates are stored on the server until the bot receives them [...], but they will not be kept longer than 24 hours.
What I am not sure is if the lost updates consume update_id values.
Dunno if that the right place to post the question.
However out of curiosity, how does 10 seconds are loaded in 2 seconds? I could have understand if an audio being loaded to the fileserver and the client is loading it afterwards. However lifestream that comes from RTSP I have got two answers,
It's either loads played content
Or the internet lifestream is behind real stream...
Anyway I would like to hear your aswers and guidance on this topic. Thanks
It's the second option. If you would stream audio in "real time" without any delay, you would have serious problems when the connection is lost or data is delayed, for example, for 100ms. Than the user wouldn't hear anything for 100ms, which would be pretty annoying. This especially happens with mobile connections, which have much higher error rates and while you move have a hard time to keep a stable connection.
Usually the acutal playback is delayed and the next seconds are buffered. When the connection is down and comes back in the buffered time frame, than the user doesn't notice that the connection was lost. In you example the connection can be lost for up to 8 seconds without any problems.