Removing an image from library => Unexpected Error, please contact support

http://springsignage.com/support/

I’ve logged an issue for the Library Tidy here:

1 Like

I have the troubleshoot.zip, how can I share it to you ?

You’ll need to upload it (Dropbox, Google Drive etc) and then share the link to it in a PM.

Ok, I will do it from home, at work I have all cloud solutions firewalled >_>

I deleted your reply as the troubleshoot can contain sensitive information. It would have been best to send the link via PM per my suggestion :slight_smile:

I’ll pass it on and we’ll have a look for you.

This is the relevant error message:

SQLSTATE[21000]: Cardinality violation: 1242 Subquery returns more than 1 row#0 /var/www/cms/lib/Storage/PdoStorageService.php(225): PDOStatement->execute(Array)
#1 /var/www/cms/lib/Factory/MediaFactory.php(630): Xibo\Storage\PdoStorageService->select('?            SE...', Array)
#2 /var/www/cms/lib/Factory/MediaFactory.php(290): Xibo\Factory\MediaFactory->query(NULL, Array)
#3 /var/www/cms/lib/Entity/Media.php(571): Xibo\Factory\MediaFactory->getParentById(92)
#4 /var/www/cms/lib/Controller/Library.php(520): Xibo\Entity\Media->delete()
#5 [internal function]: Xibo\Controller\Library->delete('92')
#6 /var/www/cms/vendor/akrabat/rka-slim-controller/RKA/Slim.php(79): call_user_func_array(Array, Array)
#7 [internal function]: RKA\Slim->RKA\{closure}('92')
#8 /var/www/cms/vendor/slim/slim/Slim/Route.php(468): call_user_func_array(Object(Closure), Array)
#9 /var/www/cms/vendor/slim/slim/Slim/Slim.php(1357): Slim\Route->dispatch()
#10 /var/www/cms/vendor/slim/slim/Slim/Middleware/Flash.php(85): Slim\Slim->call()
#11 /var/www/cms/vendor/slim/slim/Slim/Middleware/MethodOverride.php(92): Slim\Middleware\Flash->call()
#12 /var/www/cms/lib/Middleware/Actions.php(141): Slim\Middleware\MethodOverride->call()
#13 /var/www/cms/lib/Middleware/Theme.php(35): Xibo\Middleware\Actions->call()
#14 /var/www/cms/lib/Middleware/WebAuthentication.php(132): Xibo\Middleware\Theme->call()
#15 /var/www/cms/lib/Middleware/CsrfGuard.php(62): Xibo\Middleware\WebAuthentication->call()
#16 /var/www/cms/lib/Middleware/State.php(109): Xibo\Middleware\CsrfGuard->call()
#17 /var/www/cms/lib/Middleware/Storage.php(47): Xibo\Middleware\State->call()
#18 /var/www/cms/lib/Middleware/Xmr.php(36): Xibo\Middleware\Storage->call()
#19 /var/www/cms/vendor/slim/slim/Slim/Slim.php(1302): Xibo\Middleware\Xmr->call()
#20 /var/www/cms/web/index.php(124): Slim\Slim->run()
#21 {main}

It looks like your previous revision itself has two “parents” - this shouldn’t happen and might be the cause of the issue. Would it be possible to capture the output and reply with it here?

SELECT parentmedia.mediaid FROM media parentmedia WHERE parentmedia.editedmediaid = 92;

If you need help running a SQL command in Docker there is a FAQ for that here: How can I run a SQL command when using a Docker Install?

This is the result:

±--------+
| mediaid |
±--------+
| 89 |
±--------+
1 row in set (0.00 sec)

OK, so its not that…

I think I will need you to put the CMS into “Test” mode from the CMS settings and try to delete again, that should give us the exact query being run so I can see, rather than guess, where the Subquery error is coming from. Sorry!

Instead of using the fault wizard you can filter the logs by the DELETE method, with “library” in the Page filter, which will get you the set of results generated - I am expecting a similar error message as the above, with the SQL statement being logged immediately before it.

https://drive.google.com/file/d/0B7SSmEWxpFEpMzVkU2RfRXNLSVk/view?usp=sharing

I’m really stuck with this i’m afraid - is there any possibility of having your docker folder (including files) zipped up and sent over so we can see what’s really happening by debugging locally?

Failing that - any chance of remote access?

Hello, remote is hard, too many authorization to ask.
Ok to dump everything, I think there are not sensible informations on displays.
Pls let me know EXACTLY what do you need.
Also database dump ? If yes let me know how to do it.

My company has a sort of cloud system to share big files, I can use this but I need your email.

OK, no problem.

We would need your entire xibo-docker folder, including the shared volumes for cms/sql/backup and config.env - ideally having stopped the containers before archiving (if possible).

You can send it to support@springsignage.com

Hello, you should receive an email shortly.
This email contains a link to the zip.
The link will be active for 120h then it will delete.

Thanks - I am downloading that now and will revert back when I have been able to try it out.

1 Like

Many thanks for your support !

Somehow you have a single media record marked as the replace for 2 media records, which is causing the error you’ve got there.

To fix it the record you can run:

UPDATE `media` SET editedmediaid = null WHERE mediaid = 92;

The delete should be successful after that.

I am not sure how it got into this condition - that file does have a lot of revisions that previously worked OK (and i’ve deleted back several revisions to ensure that works).

1.8 has a new mode which will “delete old revision” when you do a replace - I think that this will streamline your library going forwards, so that you only ever have the active copy in the library - the others are removed as you go.

Please can you run the above SQL and let me know if that solves your issue?

Thanks

1 Like

It worked !
Rogue media deleted.
Many thanks !

What are the correct steps to follow to update a resource media ?
The new file must have the same name of the previous one ?
During the replacing the name of the media can be left blank ?

I’m almost sure that replacing procedure has something wrong… for example, now I just replaced an image with a new revision, the new image seems correctly assigned to the layouts where the previous one was in use BUT the new one is NOT pushed to displays.
Also the new and old resources are not listed on media assigned to single display, simply vanished… but I still view it in layouts.
No error on logs,all check marks are ok.