Closed MrCSharp22 closed 8 years ago
@IgorGiga if you need the fix ASAP, then please use the code from "https://github.com/RafaelYousuf/taglib-sharp-portable" by downloading the code and referencing the project in your code. Otherwise, you can wait for the maintainer to merge the pull request.
Thank you! I will wait a few more days to see if maintainer will merge the pull request... If not, then I will use yours! Btw, is the issue fixed for sure?
@IgorGiga i am using it in my app (on the verge of being released), so yeah, it is fixed.
@IgorGiga BTW that code i referenced is the same in this pull request.
Ok! That's good news!
Can confirm that this fixes the bug, I've been using the version from "https://github.com/RafaelYousuf/taglib-sharp-portable" too
OK! Thanks!
Hey guys! One question... I have implemented taglib sharp portable into my windows app, but having on small problem... Writing tags works, but it takes like 20 seconds and totally freezes the app during that process! Are you experincing the same issue?
if you have problems with freezing use async methods and wrap the long running task in 'await Task.Run(() => { //cpu bound work });'. I've not been experiencing any perfomance issues with this lib, but I'm not using it in an RT application either.
Ok! Thanks! But, do you use this lib for writing tags?
yes I do
And it writes tags instantly for you??? As I said it takes literally 20 seconds in my RT app... Don't know what is the problem...
I did use it in Windows RT (Windows 8.1) and am planning to use it in UWP (Windows 10) and did not experience this problem.
I use it in UWP app... Can you please show me your code sample for writing tags? Or you can send it to my email...
@florian what is this await Task.Run... supposed to do? Wouldn't it make more sense not to await it?
@StefanFabian no, inside Task.Run you can execute any cpu bound work (which would not be executed async else) in another thread. See here for a reference on how to use Task.Run: http://blog.stephencleary.com/2013/11/taskrun-etiquette-examples-dont-use.html
Yeah, I get that though the point why this does not block the UI is that you change the callback to an async callback and when an async callback is invoked the UI doesn't wait for it to complete. At least afaik. So this only makes sense in callbacks.
@IgorGiga did you use a custom file abstraction? Don't have time to look at my old code right now but here's the file abstraction class I used and still use to read some tags.
class FileAbstraction : TagLib.File.IFileAbstraction
{
public string Name { get; protected set; }
public Stream ReadStream { get; protected set; }
public Stream WriteStream
{
get
{
throw new NotImplementedException();
}
}
public FileAbstraction(string name, Stream stream)
{
this.Name = name;
this.ReadStream = stream;
}
public void CloseStream(Stream stream)
{
stream.Flush();
}
}
For write you'd just have to set the WriteStream to stream and open a stream that can read and write.
@StefanFabian I use this:
try
{
StatusTextBlock.Text = Resources.GetString("tagsString");
var localFile = await file.CopyAsync(localFolder, "temp.m4a", NameCollisionOption.ReplaceExisting);
var readStream = await localFile.OpenAsync(FileAccessMode.Read);
var writeStream = await file.OpenAsync(FileAccessMode.ReadWrite);
var tagFile = TagLib.File.Create(new StreamFileAbstraction(file.Name, writeStream.AsStreamForRead(), writeStream.AsStreamForWrite()));
var tag = tagFile.Tag;
tag.AlbumArtists = new string[] { artistName };
tag.Title = fileName;
tag.Album = albumName;
tagFile.Save();
tagFile.Dispose();
readStream.Dispose();
writeStream.Dispose();
}
catch
{
}
did you write StreamFileAbstraction yourself? Because as far as I Remember there was an issue with the shipped FileAbstraction and Windows RT. It's been a while though. Might be fixed but I guess it's worth a try. Also is it required to dispose tagFile if you dispose the streams yourself? I don't think I did that.
Yes... This code totally works, it's just taking 20 seconds to complete...
Don't know about dispose tagFile, probabably it isn't required...
Any catched exceptions?
no...
@StefanFabian yes you are right. The advantage of using the await keyword is that you can show a loading indicator in the UI, or may execute other commands at the same time, because the UI is still responding
@florianalexandermoser do you know if there's an advantage vs ConfigureAwait(false) and using a completed callback?
See here for when to use ConfigureAsync(false): http://blog.ciber.no/2014/05/19/using-task-configureawaitfalse-to-prevent-deadlocks-in-async-code/ Generally you don't need to use it if you use async all the way (which means you do not execute async Methods from synchronous methods, for example by using .Result) In the link above I think you will find exactly the example you are looking for. I would recommend you mark your event handlers with async and execute all async. You can disable the button for as long the operation is running if you need to.
Please, accept this pull request! I am experiencing the issue #5 in my winRT app, so if this pull request fixes that bug, PLEASE merge it ASAP!