Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thumbnail generation deletes source asset too early #3940

Open
wzur opened this issue Mar 8, 2016 · 2 comments
Open

Thumbnail generation deletes source asset too early #3940

wzur opened this issue Mar 8, 2016 · 2 comments

Comments

@wzur
Copy link
Contributor

wzur commented Mar 8, 2016

Hi there,

I've been tracking down why source asset gets deleted from the local storage before all other assets were converted.

We use very aggressive PURGE_FILES_ON_DELETE option with S3 bucket as an external storage to achieve a small footprint of our local storage.

I've tracked that behavour down to handleCaptureThumbFailed & handleCaptureThumbFinished kFlowHelper class - these don't use conditionalAssetLocalFileSyncsDelete - instead they simply call handleLocalFileSyncDeletion which unconditionally deletes all ready assets from the local storage.

As I don't know the intended workflow I'm not in the position to propose a correct patch.

Waldemar

@kaltura-hooks
Copy link

Hi @wzur,

Thank for you reporting an issue and helping improve Kaltura!

To get the fastest response time, and help the maintainers review and test your reported issues or suggestions, please ensure that your issue includes the following (please comment with more info if you have not included all this info in your original issue):

  • Is the issue you're experiencing consistent and across platforms? or does it only happens on certain conditions?
    please provide as much details as possible.
  • Which Kaltura deployment you're using: Kaltura SaaS, or self-hosted?
    If self hosted, are you using the RPM or deb install?
  • Packages installed.
    When using RPM, paste the output for:
    # rpm -qa \"kaltura*\"
For deb based systems:
    # dpkg -l \"kaltura-*\"
  • If running a self hosted ENV - provide the MySQL server version used
  • If running a self hosted ENV - is this a single all in 1 server or a cluster?
  • If running a self hosted ENV, while making the problematic request, run:
    # tail -f /opt/kaltura/log/*.log /opt/kaltura/log/batch/*.log | grep -A 1 -B 1 --color \"ERR:\|PHP\|trace\|CRIT\|\[error\]\"

and paste the output.

  • When relevant, provide any screenshots or screen recordings showing the issue you're experiencing.

For general troubleshooting see:
https://github.com/kaltura/platform-install-packages/blob/Jupiter-10.13.0/doc/kaltura-packages-faq.md#troubleshooting-help

If you only have a general question rather than a bug report, please close this issue and post at:
http://forum.kaltura.org

Thank you in advance,

@wzur
Copy link
Contributor Author

wzur commented Mar 8, 2016

This issue is not connected to any distribution or deployment - the problem is in the import's batch flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants