I'm trying to send 2 files to my Apple Watch app. It worked initially, but now I'm getting 2 errors printed in the console.
WCSession.default.transferFile(fileURL1, metadata: ["name":"first"])
WCSession.default.transferFile(fileURL2, metadata: ["name":"second")
Who is printing the error - is it my the test app on the iPhone?
Can I transfer 2 files in sequence, or are there limitations - do I need to wait for the first transfer to complete?
2018-11-18 11:05:53.010374-0500 SimpleWatchConnectivity[836:23347]
[WC] -[WCFileStorage enumerateFileTransferResultsWithBlock:] could not
load file data at path
/var/mobile/Containers/Data/Application/C07047D9-87F7-4CBD-AE79-AAE26D93A400/Library/Application
Support/com.apple.watchconnectivity/46CAD076-37A8-4B60-A93E-F0F21F457593/FileTransfers/D9E589D8-E21B-4A34-9A29-8D6B53E997D5/file-transfer-result
The documentation makes it seem like the files are enqueued, so I'm not sure as to what is causing the error:
/** The system will enqueue the file and transfer it to the
counterpart app at an opportune time. The transfer of a file will
continue after the sending app has exited. The counterpart app will
receive a delegate callback on next launch if the file has
successfully arrived. The metadata dictionary can only accept the
property list types. */
Related
I followed the top answer in this StackOverflow post to use ffmpeg-python extract a .wav file from a YouTube URL (into the pcm_s16le codec), which was played successfully by my local audio player (Mac's Music).
However, as I tried to read it using scipy.io's wavefile,
samplerate, data = wavfile.read(wav_fname)
the following error message is thrown:
"WavFileWarning: Reached EOF prematurely; finished at 1192015 bytes, expected 4294967303 bytes from header."
May anyone suggest what's going on?
I have successfully extracted a .wav file which is successfully read by my local music player. However, it is failed to be recognized by scipy.io's wavefile. And I am not sure why.
I am using the Linux sendmsg() function to send a file-descriptor to another process over a Unix Socket along with some data payload. I make multiple calls to sendmsg. In the recvmsg() companion call inside the destination process, I get the file descriptor using something like "fdptr = (int *) CMSG_DATA(cmsg); memcpy(fdptr, myfds, NUM_FD * sizeof(int));" What I am noticing that each time I look at the file descriptor, the file descriptor is yet a DIFFERENT number than it was in the prior recvmsg() call.
My question: Is the destination process holding open a bunch of open descriptors to the same file/hardware?? Do I need to close the descriptors?
What would happen if I was not to try to copy the descriptor with "memcpy(fdptr, myfds, NUM_FD * sizeof(int));" and essentially 'left it inside' CMSG_DATA(cmsg)? Would there be some descriptor with an unknown number sitting out there? Had I not copied it out, I would have never seen it was essentially yet another descriptor number.
I'm looking to fetch recorded data using LogBook in a custom Movesense firmware. How do I get the correct byte stream offset for the next GET call when receiving HTTP_CONTINUE?
I'm trying to implement these steps as described in DataStorage.md:
### /Logbook usage ###
To get recording from the Movesense sensors EEPROM storage, you need to:
1. Do **GET** on */Logbook/Entries*. This returns a list of LogEntry objects. If the status was HTTP_OK, the list is complete. If the result code is HTTP_CONTINUE, you must GET again with the parameter StartAfterId set to the Id of the last entry you received and you'll get the next entries.
2. Choose the Log that you are interested in and notice the Id of it.
3. Fetch the descriptors with **GET** to */Logbook/byId/<Id>/Descriptors*. This returns a bytestream with the similar HTTP_CONTINUE handling as above. However you **must** keep re-requesting the **GET** until you get error or HTTP_OK, or the Logbook service will stay "in the middle of the stream" (we hope to remove this limitation in the future).
4. Fetch the data with **GET** to */Logbook/byId/<Id>/Data*. This returns also a bytestream (just like the */Logbook/Descriptors* above).
5. Convert the data using the converter tools or classes. (To Be Continued...)
The problem is basically the same for step 3 and 4. I receive a whiteboard::ByteStream object in the onGetResult callback function but I don't know how to get the correct offset information from it.
I've found a number of different methods seemingly concerning different aspects of number of bytes in ByteStream.h (length, fullSize, transmitted, payloadSize and serializationLength) but I just can't get it working properly.
Basically I would like to do something like this in onGetResult:
if (resultCode == whiteboard::HTTP_CODE_CONTINUE) {
const whiteboard::ByteStream &byteStream = rResultData.convertTo<const whiteboard::ByteStream &>();
currentEntryOffset += byteStream.length();
asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(), AsyncRequestOptions::Empty, currentEntryIdToFetch, currentEntryOffset);
return;
}
The basic idea is to do the same call again.
So if you do:
asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(),AsyncRequestOptions::Empty, currentEntryIdToFetch);
and get the response HTTP_CONTINUE, do:
asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(),AsyncRequestOptions::Empty, currentEntryIdToFetch);
Until you get HTTP_CONTINUE or an error.
If the result code is HTTP_CONTINUE, you must GET again with the parameter StartAfterId set to the Id of the last entry you received and you'll get the next entries.
Might be a bit cryptic but do another asyncGet to the exact same resource until you get HTTP_OK or an http error code.
Also, note that you need to decode the data, a python script can be found here in this answer
I am trying to make a patch that plays audio when a bang is pressed. I have put a symbol so that I don't need to keep reimporting the file. However it works sometimes but not all the time.
A warning in the Pd console reads: Start requested with no prior open
However I have imported an audio file
Is there something that I have done wrong?
Use [trigger] to get the order-of-execution correct.
One problem is, that whenever you send a [1( to [readsf~] you must have sent an [open ...( message directly beforehand.
Even if you have just successfully opened a file, but then stopped it (with [0() or played it through (so it has been closed automatically), you have to send the filename again.
The real problem is, that your messages are out of order: you should never have a fan-out (that is: connecting a message outlet to multiple inlets), as this will create undefined behavior.
Use [trigger] to get the order-of-execution correct.
(Mastering [trigger] is probably the single most important step in learning to program Pd)
I am building a tool to replay logs. Manually parsing the logs is annoying, so I'm wondering if there is a way to simply load a message from the log.
Also, I am not against just using a third-party replay tool if one exists.
First read the log file by any mean you want, getting the individual lines (there is one message per line).
Then build a Data Dictionary:
// Use the version of the XML dictionary that is right for you
FIX::DataDictionary dd("FIX44.XML");
Then, for each line (as std::string str), build a message:
FIX::Message msg(str, dd, false);
Finally, handle the message just like your FIX::Application does, or better, call
yourFixApplication.fromApp(msg, mySessionID);
ValidFIX Log analyzer is an online log parser that makes a good job:
http://www.validfix.com/fix-log-analyzer.html