Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_onewaysync (Read 114723 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_onewaysync

Reply #200 –
Quote from: 2sevens on
Are there any known conflicts or am I doing something wrong??  It looks like an excellent tool & I'd love to be asble to use it.  Thanks in advance for any help or suggestions.

Error code 3221225501 = 0xC000001D = illegal instruction.
Probably this component was built with SSE2 instructions enabled, and your CPU doesn't support them.

Re: foo_onewaysync

Reply #201 –
Thanks for letting me know.  That old CPU is certainly creaking with age now.  Maybe time to retire it.

Appreciate you taking the trouble to help :)

Re: foo_onewaysync

Reply #202 –
Quote from: lvqcl on
Error code 3221225501 = 0xC000001D = illegal instruction.
Probably this component was built with SSE2 instructions enabled, and your CPU doesn't support them.
Possible, but I just double checked, there are no such optimizations. In principle, it should run fine on WinXP. Asking google shows that sometimes also bad drivers or a messed up windows installation can result in this error. My suggestion is to try with a clean windows install.

Re: foo_onewaysync

Reply #203 –
If you are building with MSVC 2013 or newer, SSE2 optimizations are enabled by default, and must be explicitly disabled.

Re: foo_onewaysync

Reply #204 –
The component is built with MSVC 2012.

Re: foo_onewaysync

Reply #205 –
Quote from: zimjo on
It is assured that generation of the PCM file is finished before the conversion command is executed.
The component does not make any distinction between different encoders. It simply executes the commands that you see printed to the console. So, if it works with lame, qaac must have some special requirements.
The latest version 0.6.1 has a workaround for this issue.

Re: foo_onewaysync

Reply #206 –
Quote from: zimjo on
Quote from: zimjo on
It is assured that generation of the PCM file is finished before the conversion command is executed.
The component does not make any distinction between different encoders. It simply executes the commands that you see printed to the console. So, if it works with lame, qaac must have some special requirements.
The latest version 0.6.1 has a workaround for this issue.


Thank you! Everything is working great now.

I really appreciate the hard work you have put in to developing the plugin. Keep up the good work!

Re: foo_onewaysync

Reply #207 –
Quote from: kode54 on
If you are building with MSVC 2013 or newer, SSE2 optimizations are enabled by default, and must be explicitly disabled.
AFAIK it was MSVC 2012.

Re: foo_onewaysync

Reply #209 –
Hi again,
I really thank you again for how you made it work with qaac after I pointed it out a while back.

This time, I wanted to ask about something different. I know that individual songs can be synced by right clicking on them and choosing File Operations>One Way Sync> Last Used.
But is there a function for dynamically choosing which playlists to sync other than choosing them each time in the "tasks" preference page?

The reason I'm asking is because I'm trying to make two buttons on my foobar2000 skin for "Sync All Playlists" and "Sync Current (Active) Playlist", which is when I realized that the fb.RunContextCommand used for buttons only accepts functions in the context menu. That menu currently only shows File>One Way Sync>(NameofDevice).

This is when I realized that it would be helpful if expanded context menu options could be added as such:
File>One Way Sync>(NameofDevice)>Sync All Playlists
File>One Way Sync>(NameofDevice)>Sync Current Playlist
File>One Way Sync>(NameofDevice)>Sync Selected Playlists
In which the first two would do as stated, and the "Sync Selected Playlists" would run the current method of only syncing the playlists that were pre-selected in the tasks page.

Would it be possible for you to add these options in a future version, or is there already an option for these in One Way Sync somewhere that I am just overlooking?

Re: foo_onewaysync

Reply #210 –
From what you write, it seems you are talking about the main menu. Anyways, that would be the proper place for such a command. In principle, this can be done and I might look into it.

Re: foo_onewaysync

Reply #211 –
First of all, big thanks to the dev who donates his time to develop this plugin for the community.

I decided to give this plugin a try after I finally abandoned m-TAGS which was incompatible with most of the synchronization/conversion plugins out there.

Unfortunately even though I didn't configure anything fancy I experienced that OWS modifies some of my source files. By the time I realized this, many of my files have been changed and had to be restored from backup. Checking a few of them revealed that mostly the image tag has been changed, but some files also had changes in the middle of them (according to KDiff3)

Considering the circumstances I'm unable to currently make use of this plugin, however I'm glad if I can help tracing down this problem, so maybe it can be fixed.

Please let me know which files are needed to replicate the issue.

Re: foo_onewaysync

Reply #212 –
Make sure to uncheck the options 'One Way Sync->Store path to lossy file in tags', 'One Way Sync/Devices->Always embed cover art', and maybe also 'One Way Sync/Devices->Copy cover art'. Then source files should no longer become modified. In any case, OWS only alters meta information, i.e. in the tags/embedded cover art, not in the music.

Re: foo_onewaysync

Reply #213 –
Quote from: zimjo on
Make sure to uncheck the options 'One Way Sync->Store path to lossy file in tags', 'One Way Sync/Devices->Always embed cover art', and maybe also 'One Way Sync/Devices->Copy cover art'. Then source files should no longer become modified. In any case, OWS only alters meta information, i.e. in the tags/embedded cover art, not in the music.

Thanks for the tip, this solves my issue! To be honest I didn't expect a plugin called One Way Sync to touch any of the source files. I thought all of these alterations will only take place in the destination files. Even if it's only the metadata, any modification can cause problems if the source files are hashed for some reason (for instance because they are shared by a torrent client).

Just out of curiosity why did you decide to go this way?

ps: I think a warning message would be nice when user selects one of these options
 

Re: foo_onewaysync

Reply #214 –
Quote from: belidzs on
Just out of curiosity why did you decide to go this way?
'One Way Sync/Devices->Always embed cover art'
It would be very slow (USB sticks etc.) or even impossible (MTP devices) to modify the file at the destination. Creating a temporary copy would be slower as well.

'One Way Sync->Store path to lossy file in tags'
When conversion speed is low, it makes sense to store the converted file at the path of the lossless source. Then, if the user decides to move the lossless source file to another path, the converted file can no longer be found by OWS. Storing the path as a tag resolves this problem.

Re: foo_onewaysync

Reply #215 –
Quote from: zimjo on
Quote from: belidzs on
Just out of curiosity why did you decide to go this way?
'One Way Sync/Devices->Always embed cover art'
It would be very slow (USB sticks etc.) or even impossible (MTP devices) to modify the file at the destination. Creating a temporary copy would be slower as well.

'One Way Sync->Store path to lossy file in tags'
When conversion speed is low, it makes sense to store the converted file at the path of the lossless source. Then, if the user decides to move the lossless source file to another path, the converted file can no longer be found by OWS. Storing the path as a tag resolves this problem.

I totally agree with the second point. However I noticed that all the converted files are first saved to the temporary directory and only after all of them are converted are they copied to the final device.

Isn't this temporary state would be perfect to add the cover art?

Re: foo_onewaysync

Reply #216 –
Not all files require conversion. I agree with your point, but it does not apply to those files being copied without prior conversion.

Re: foo_onewaysync

Reply #217 –
First, thank you for this awesome plugin. It is just what I was seeking in order to sync my playlist with Android phone.

Strangely I cannot make it work completely. Since I don't need any transcoding, I set my encoder to simple `copy` utility in Windows 10.

Copying to MTP storage works perfectly until the plugin tries to copy .m3u file or near that time. Then plugin freezes so do Explorer if I try to look up MTP folder. After several minutes the storage disconnects. It is very strange because the plugin perfectly copies all files before that for pretty long time. Any idea what might be the problem?

Re: foo_onewaysync

Reply #218 –
Your encoder settings should not matter, unless you check 'Convert lossless files' or 'Convert these lossy file types'.

Whats the console output when that happens?

As a workaround you can set some folder on your computer as the destination. Then, copy the contents of that folder to your android using windows explorer. Do playlist copy without issue when done this way?

Re: foo_onewaysync

Reply #219 –
Quote from: zimjo on
As a workaround you can set some folder on your computer as the destination. Then, copy the contents of that folder to your android using windows explorer. Do playlist copy without issue when done this way?

Sorry for long delay. I tried what you said and now it's obvious that there is no issue with plugin. My phone doesn't want to transfer .m3u files for some reason. If I rename file's extension it is copied without issues. Now I'm going to figure why it is so picky.  ::)  Thanks for help!

Re: foo_onewaysync

Reply #220 –
Could you make playlist addition as an option? It seems that MTP allows devices to restrict media formats such as playlists for instance.

UPD: Maybe I'm wrong and this is just a bug. Actually it is filed in Android Bug Tracker but not confirmed yet - https://issuetracker.google.com/u/1/issues/67428227

Re: foo_onewaysync

Reply #221 –
Indeed MTP can have special treatment for certain file types, see e.g. here. I believe it is the drivers choice to enforce such special treatment.
So, you are either having a driver issue or you are suffering from the bug you linked to.
Try updating your android, as well as the phone drivers on your PC. Then, if you still observe the same problem, I suggest you open a new issue in android bug tracker.

Re: foo_onewaysync

Reply #222 –
Would it be possible to have the component save playlists as m3u8 files instead of m3u? I noticed some issues with certain device players (e.g. Poweramp, Black Player) reading non-Western characters in m3u playlist files.

I know you can just rename them afterwards but is there any hidden benefit to leaving them as m3u?

Re: foo_onewaysync

Reply #223 –
While this might work for Poweramp, it will surely result in problems with other players. There is always some player, where the one or the other does not work. There are a number of players that refuse to recognize m3u8 as playlist file. Therefore, I consider m3u to be the more compatible extension, even though you are technically correct. Since there are players where even m3u8 is not treated as proper unicode, but in the local codepage instead, I believe any attempt to find an extension that fits all is bound to fail.

Maybe there is an option in those players to change the default codepage?

Re: foo_onewaysync

Reply #224 –
Is this plugin only supporting wired sync? I expected it also supports wire-less protocols (ftp or smb would come handy)

I'm using sharing PC library with portable in three steps - 1) conversion from lossless source to Opus via fixed converter profile to local folder 2) embedding cover within foobar and removing padding 3) send via ftp to device using Beyond Compare and remote folder sync profile.
This workaround is already rather straightforward and quick, can OneWaySync furthermore improve/consolidate the process?