[v6 General Discussion] schedule saving options?
12 CommentsSorted by Oldest First
Have you tried removing the background videos in the master files so that you can drag and drop them when you load your schedule for worship? Save them without backgrounds and drag and drop your videos into the schedule on your live machine? This should reduce the size of your saved schedules (in theory anyway). Hope this helps.
Adam
Adam
Apparently the developers deemed portability was only option for schedules. When I pointed this huge increase in file size I was told they would add the don't add media to schedule option to their features to add list.
I find it hard to think that most EW2009 customers added media to their schedules. In both versions the song database doesn't store media with songs. By adding media to schedule you're adding extra copies of media to your storage devices. If you used same video background for one item in your schedule, like greeting or prayer, after a year you would literally have 53 copies on your drive; more if you used it in other service schedules.
I find it hard to think that most EW2009 customers added media to their schedules. In both versions the song database doesn't store media with songs. By adding media to schedule you're adding extra copies of media to your storage devices. If you used same video background for one item in your schedule, like greeting or prayer, after a year you would literally have 53 copies on your drive; more if you used it in other service schedules.
wow.just.wow.
not only does it take up space on the local storage system, but it will quickly be filled, as we save each service and events schedule for reference.
On top of that, it now takes several minutes to load and save a schedule because of that size issue, which now makes it un-useable for swapping schedules ad-hoc, that also happens for our use.
Even if we had a brand new laptop/computer at the church, these issues would still make it a challenge. had I known this was going to happen, I would not have removed the previous version.
Does EW support say when this "feature" will be added that was on the previous version, and that they felt they needed to remove? do they even communicate with actual real life users of the software?
not only does it take up space on the local storage system, but it will quickly be filled, as we save each service and events schedule for reference.
On top of that, it now takes several minutes to load and save a schedule because of that size issue, which now makes it un-useable for swapping schedules ad-hoc, that also happens for our use.
Even if we had a brand new laptop/computer at the church, these issues would still make it a challenge. had I known this was going to happen, I would not have removed the previous version.
Does EW support say when this "feature" will be added that was on the previous version, and that they felt they needed to remove? do they even communicate with actual real life users of the software?
Have you tried removing the background videos in the master files ...Adamyes, this works as a workaround, but is not the solution. this takes time and training. I can choose what I want, but the person running the media may not know what I want, so I have to set them up. THanks, but I am already doing this as a workaround. I just don't get why a new version has featuresets/functionality removed. still very frustrated.
Unfortunately (as I understand it from reading posts and looking at the software myself in my testing before purchasing) it seems in trying to solve one issue (users messing up schedules because they moved around files) the developers have actually introduced a much more serious problem.
What I suspect is happening is that instead of referring to a resource (picture, video) by reference the developers are 'embedding' a full copy of the resource in the [service] schedule file. If this is the case, you'll forgive me for saying, that is a 'bad decision'. What should happen is that you have one physical copy of the (storage expensive) graphical resource. The software should then reference it, by relative folder structure. So, for argument's sake, if the EasyWorship root folder was "C:Program FilesEasyWorship" and resources were in, for example, "C:Program FilesEasyWorshipResourceGraphicsSomePicture.jpg" then EasyWorship would reference the graphic file as "ResourceGraphicsSomePicture.jpg". That is, relative to the EasyWorship 'root' folder.
Reading this thread I find confirmation in some of the behaviour I see in the software - if I have a song saved and I edit the song you cannot 'refresh' the song in the schedule, you have to remove it and replace it. If you change a Song or Bible verse theme which has already been applied to a song then you cannot refresh (by saving the theme in the song database) the theme of the song in the schedule - you have to reapply the theme.
If this is the case and if a source resource (picture, video) is used in a theme and then the theme applied to ten songs then I suspect that the graphic resource is going to be copied ten times - once for each song. If so that is very inefficient and will lead, as seen, to cases where the schedule file is 1GB in size.
I believe the software should and must use graphic resources by reference, not by copy. As to the reason why Softouch did this - people messing up their graphics file linking when they moved things around well, of course they could be told not to do that but also the system could/should have an option to 'relink/reference' links to graphics resource files. I'll give you an example: Adobe Lightroom, you're talking there about hundreds, thousands of graphics files of multi-gigabytes in size. Lightroom accesses photo files by reference, a relative folder path. If someone messes around with the folder structure and opens a Lightroom database file (i.e. an EasyWorship schedule file) Lightroom says the source file can't be found, gives you to option to find it and then once you do it will automatically refresh the relative links for all the other photos in the database to the source photo files. So it can be done.
Softouch team if my analysis is (broadly) correct can you please reconsider/improve the design change you made in this new version.
What I suspect is happening is that instead of referring to a resource (picture, video) by reference the developers are 'embedding' a full copy of the resource in the [service] schedule file. If this is the case, you'll forgive me for saying, that is a 'bad decision'. What should happen is that you have one physical copy of the (storage expensive) graphical resource. The software should then reference it, by relative folder structure. So, for argument's sake, if the EasyWorship root folder was "C:Program FilesEasyWorship" and resources were in, for example, "C:Program FilesEasyWorshipResourceGraphicsSomePicture.jpg" then EasyWorship would reference the graphic file as "ResourceGraphicsSomePicture.jpg". That is, relative to the EasyWorship 'root' folder.
Reading this thread I find confirmation in some of the behaviour I see in the software - if I have a song saved and I edit the song you cannot 'refresh' the song in the schedule, you have to remove it and replace it. If you change a Song or Bible verse theme which has already been applied to a song then you cannot refresh (by saving the theme in the song database) the theme of the song in the schedule - you have to reapply the theme.
If this is the case and if a source resource (picture, video) is used in a theme and then the theme applied to ten songs then I suspect that the graphic resource is going to be copied ten times - once for each song. If so that is very inefficient and will lead, as seen, to cases where the schedule file is 1GB in size.
I believe the software should and must use graphic resources by reference, not by copy. As to the reason why Softouch did this - people messing up their graphics file linking when they moved things around well, of course they could be told not to do that but also the system could/should have an option to 'relink/reference' links to graphics resource files. I'll give you an example: Adobe Lightroom, you're talking there about hundreds, thousands of graphics files of multi-gigabytes in size. Lightroom accesses photo files by reference, a relative folder path. If someone messes around with the folder structure and opens a Lightroom database file (i.e. an EasyWorship schedule file) Lightroom says the source file can't be found, gives you to option to find it and then once you do it will automatically refresh the relative links for all the other photos in the database to the source photo files. So it can be done.
Softouch team if my analysis is (broadly) correct can you please reconsider/improve the design change you made in this new version.
I think that assessment is pretty much spot on. though with 2009, when saving, there was an option, as I recall to embed - they called it pack videos in schedule - it was a checkbox. which is what made me wonder, since the functionality was there, why remove it and force embedding.
If you enforce embedding, does this mean that the background is not available for other songs, or even that it is not available if you edit the song that originally came with the background. Keeping the songs and backgrounds separate certainly seems to have advantages.
It's embedding a copy of media in schedule. So you have original media file plus copies in schedules. The only good thing is only one copy included in schedule; so four songs using same background are sharing the one copy not getting their own individual copies. However I usually choose background for each song so I don't many songs sharing media.
We also use 5 minute countdown videos and they are over 100 MB each (most over 200 MB) so these extra copies would add 5-10 GB per year to our storage requirements locally and in Dropbox.
We also use 5 minute countdown videos and they are over 100 MB each (most over 200 MB) so these extra copies would add 5-10 GB per year to our storage requirements locally and in Dropbox.
Hi,
Firstly, I can see why they have done it - in theory it means you can copy your schedule file from one machine to another without having to worry about media files being copied. For the less technically minded person it makes it easier to set up on one machine and have your schedule running on another machine at church.
However, I am very surprised the software forces this to be the option as it is so inefficient in terms of file size.
Firstly EW 6 already makes a copy of media in its resources directories (we have just come from 2007 where links were stored). I felt the design reason for this was portability i.e. so you can properly set up a shared resource profile on drop box/google drive/etc (not officially a feature at the moment?) which would have all the resources in it. As has already been mentioned all that needs to be stored in the file is the local path relative to profile. Yes there is the risk that the resource may be deleted but that should simply result (as also mentioned) in a warning and option to find the resource again (which if selected should simply copy the resource back into the profile directory).
The good news is that this really should only take one of their developers a couple of hours to put right. I expect/hope there to be a fix soon because those file sizes are simply unacceptable.
Firstly, I can see why they have done it - in theory it means you can copy your schedule file from one machine to another without having to worry about media files being copied. For the less technically minded person it makes it easier to set up on one machine and have your schedule running on another machine at church.
However, I am very surprised the software forces this to be the option as it is so inefficient in terms of file size.
Firstly EW 6 already makes a copy of media in its resources directories (we have just come from 2007 where links were stored). I felt the design reason for this was portability i.e. so you can properly set up a shared resource profile on drop box/google drive/etc (not officially a feature at the moment?) which would have all the resources in it. As has already been mentioned all that needs to be stored in the file is the local path relative to profile. Yes there is the risk that the resource may be deleted but that should simply result (as also mentioned) in a warning and option to find the resource again (which if selected should simply copy the resource back into the profile directory).
The good news is that this really should only take one of their developers a couple of hours to put right. I expect/hope there to be a fix soon because those file sizes are simply unacceptable.
thanks. and I understand. but I have to disagree, and say that I do not understand why they did this as the most simple installation isn't going to be portable. it has been my experience that for P&W (primary use), there is one computer at the church and it is the one that the schedule is created and run - so no portability is required. secondly, in the previous version (2009), there was options in the save message box that allowed the choice to embed the videos, it seems to me that this functionality was apparently, purposefully removed, and not documented.
I hope that it is an "easy fix", but whether easy or complex, it was there in the previous version, and now it is not there. will wait and see, and use time consuming, inconvenient, workarounds until then. at least there is a workaround, it would be another hurdle to have to revert everything back to powerpoint.
I hope that it is an "easy fix", but whether easy or complex, it was there in the previous version, and now it is not there. will wait and see, and use time consuming, inconvenient, workarounds until then. at least there is a workaround, it would be another hurdle to have to revert everything back to powerpoint.
Hi,
Just to clarify - I can see how they made the decision - I don't in anyway agree with it though.
I have also discovered a workaround although
1. Do this at your own risk - if you break something it is not my fault!
2. Don't blame me if it goes wrong mid-service!
3. Do this at your own risk and don't blame me if you get an exception error mid service!
4. This might not/probably won't future proof your schedule files
5. Sorry if this upsets someone at EW
Easy worship like many other packages (microsoft office for example) stores its data in a zip files - it's just it doesn't call them that. This means you can edit the contents of them with a zip editing package (I am using 7-Zip file manager).
Basically use the zip packge to explore your directories. Inside the media file you will see a media directory. Delete the media directory from it. Your done.
As long as the media has already been added to your EasyWorship database the file should reload.
In the test I just did - I had a couple of songs, a couple of videos and a powerpoint file. The file was originally 225,000K - after 'edit' it was just 207K - quite a dramatic drop in file size!!!
It all seems to work fine. Of course I have not extenively tested this so can't be sure. I am guessing there is some name look up thing going on in that background so that the schedule file version of a media element overides the database one - in this case the schedule file media element is not there so it simply uses the default one.
This method might go belly up if the media database keys change - or possible if media elements with the same filename are used. In which case a file you can open now might not be possible in a couple of months time- hard to tell. However given the compression level that is not bad for now.
What it most importantly shows - is this really should be a simple fix for EW to make. It should be no more than a few minutes programming to put the feature not to save the media path. However, I wonder if it was a feature that was pulled because it was breaking something that I have not yet encountered (like database key changes).
Hope this is helpful
God bless
RevDr
Just to clarify - I can see how they made the decision - I don't in anyway agree with it though.
I have also discovered a workaround although
1. Do this at your own risk - if you break something it is not my fault!
2. Don't blame me if it goes wrong mid-service!
3. Do this at your own risk and don't blame me if you get an exception error mid service!
4. This might not/probably won't future proof your schedule files
5. Sorry if this upsets someone at EW
Easy worship like many other packages (microsoft office for example) stores its data in a zip files - it's just it doesn't call them that. This means you can edit the contents of them with a zip editing package (I am using 7-Zip file manager).
Basically use the zip packge to explore your directories. Inside the media file you will see a media directory. Delete the media directory from it. Your done.
As long as the media has already been added to your EasyWorship database the file should reload.
In the test I just did - I had a couple of songs, a couple of videos and a powerpoint file. The file was originally 225,000K - after 'edit' it was just 207K - quite a dramatic drop in file size!!!
It all seems to work fine. Of course I have not extenively tested this so can't be sure. I am guessing there is some name look up thing going on in that background so that the schedule file version of a media element overides the database one - in this case the schedule file media element is not there so it simply uses the default one.
This method might go belly up if the media database keys change - or possible if media elements with the same filename are used. In which case a file you can open now might not be possible in a couple of months time- hard to tell. However given the compression level that is not bad for now.
What it most importantly shows - is this really should be a simple fix for EW to make. It should be no more than a few minutes programming to put the feature not to save the media path. However, I wonder if it was a feature that was pulled because it was breaking something that I have not yet encountered (like database key changes).
Hope this is helpful
God bless
RevDr
Hi,
Oh and just to add to the previous email. Have just discovered - to my surprise - that once the media path has been removed you can edit the schedule file - I just added another video clip - and the saved schedule file stays small!
RevDr
Oh and just to add to the previous email. Have just discovered - to my surprise - that once the media path has been removed you can edit the schedule file - I just added another video clip - and the saved schedule file stays small!
RevDr
Forums Migration
ASUS notebook.pentium 2.3ghz
4 g RAM
300g HD (2 partitions, both have well over 50%free)
previous ews files, range in size to about 1.5 meg - 5 songs, each with video background
current ewsx - 1 gig!!!!!! - 5 songs, each with video background
aughghgghhg, any help is appreciated.