Firstly thanks to everybody on the forum who have posted about transcoding, as without this information I wouldn't have got anywhere....
So, as previously discussed elsewhere. I simply extracted the contents of the flac-i386_341_225.zip (I'm on Linux) file from the Addons page on the TwonkyVision site into my cgi-bin directory, and I changed my clients.db so that for the DSM-320 the flac line now reads MT:flac audio/x-flac instead of MT:flac audio/flac. Initially this seemed to work fine, I could call up flac files, and they would be transcoded and play on the DSM, and I could move onto the next track in an album or playlist.
However I soon noticed some issues:
1. My other UPNP client, a Roberts Internet Radio, was now being sent transcoded audio, even though it can play flac natively.
2. Total track times on the DSM were always displayed as 9 minutes 54 seconds.
3. After playing a complete song the DSM always failed to move on automatically to the next song in the album/playlist. The http log just showed it being sent the last 16k chuck of data for the song, again and again. The DSM had to be rebooted to recover. Even when the Roberts was receiving trancoded wav files, it didn't share this problem, so this looks like another DSM-320 issue:!:
I could live with the first two but the last problem would make transcoding unworkable for me.
The first problem was easily solved by setting up the Roberts as an OXX Alto (a device based on the same chipset) in the Clients config page, and then editing the Clients.db entry for OXX Alto so that it included a MT:flac audio/flac line.
My initial attempt to fix the other problems centered on trying to store track times for my flac files in the TwonkyMedia database, as I had noticed that they were missing. I thought that if Twonky knew the track time then this would be sent to the DSM, and everything would be OK. I ended up using a mock iTunes database file to import track times into the Twonky database, however this didn't improve anything, so I had to have another think.
I'd noticed that if I played wav files that had already transcoded, that were still in the cache, then I had no problems. This made me look at the source code for the cgi-flac plugin, to see what was going on....
The way transcoding is setup by default is that the cgi-flac plugin starts decoding the flac file, then waits 2 seconds (2000ms), for some of the wav file to be written to the cache, and then it allows Twonky to start streaming the file down to the client, while the rest of the track is still being decoded. This configuration should allow low power servers, like a NAS, to perform the transcoding on the fly, whilst the track is being played back.
However, It appears that the DSM-320 can't properly deal with a transcoded stream that is still being written to, whereas, other devices such as my Roberts radio can. Thanks D-Link!.
The way I have solved this problem is by changing the cgi-flac plugin to always wait for the file to be completely transcoded to wav, before allowing Twonky to start sending it to the DSM. I run Twonky on my PC, and the average flac file only takes about 2 seconds to decode, so I'm not noticing any more of a time lag before a song starts than I would when using the original plugin. I also always encode my flac files with maximun compression, as this seems to speed up decoding. My PC is fairly new with an AMD dual core processor, but I wouldn't say that it's top of the range. Therefore I think that this solution could work for a lot or people. Unfortunately if you have a NAS, I'm guessing that the decode times would be unacceptable.
The portion of the cgi-flac.c Linux code I modified was at the end of the file:
Code: Select all
default:
sleep(2000);
cat_file(outfile,1/*TRUE*/);
waitpid(pid,NULL,0);
free(outfile);
return 0;
break;
Code: Select all
default:
wait(NULL); //Wait for child process to end
cat_file(outfile,0/*FALSE*/); //File not growing
free(outfile);
return 0;
break;
Code: Select all
if (CreateProcess (strPath, strStart, NULL,NULL, FALSE, 0, NULL, NULL, &si, &pi)) {
Sleep(2000);
// Do not wait until child process exits.
cat_file(outfile,TRUE); // growing
WaitForSingleObject (pi.hProcess, INFINITE);
//fprintf(stderr, "wait for child...done\n");
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
free(outfile);
return 0;
}
Code: Select all
if (CreateProcess (strPath, strStart, NULL,NULL, FALSE, 0, NULL, NULL, &si, &pi)) {
//Wait until child process exits.
WaitForSingleObject (pi.hProcess, INFINITE);
//fprintf(stderr, "wait for child...done\n");
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
cat_file(outfile,FALSE); //not growing
free(outfile);
return 0;
}
As the cache limit that can be set in the config pages doesn't seem to apply to transcoded wav files, I've added a simple cron job that will delete any files that haven't been accessed in the last hour. It's just a script file in my /etc/cron.hourly directory, containing the following line:
Code: Select all
find /usr/local/mediaserver/twonkymedia.db/cache/*.wav -amin 60 -delete
On Windows you could use a batch file run as a Scheduled Task to tidy up the cache, or possibly a "Disk Cleanup" utility.
My flac files now play as reliably as my mp3s. Success!
I have compiled new versions of the cgi-flac plugin for the AMD64 architecture on Linux, and also for Windows, so if anyone wants a copy to try out, then drop me a PM with your email.
Finally thanks to TwonkyVision for everything they have done in providing the transcoding plugin architecture, the cg-flac source code, and the editable clients database, that have made this all possible (holding back a tear here). Without Twonky my DSM-320 would have been sent to the scrapheap long ago...
