Skip to content
Commits on Feb 6, 2016
  1. @ffdixon
  2. @ffdixon

    Update index.html

    ffdixon committed
    Bump the copyright date.
Commits on Feb 4, 2016
  1. @ritzalam

    Merge pull request #3003 from ritzalam/fix-issue-2812-v2

    ritzalam committed
     - fix issue 2812 by setting end time when last user leaves
  2. @ritzalam
  3. @ritzalam

    Merge pull request #3001 from bigbluebutton/getRecordings-merged-enha…

    ritzalam committed
    …ncements
    
    Get recordings merged enhancements
  4. @ritzalam

    Change API version to 1.0

    ritzalam committed
  5. @ritzalam

    Merge pull request #2999 from ritzalam/make-desktop-sharing-stop-when…

    ritzalam committed
    …-tunneling
    
     - desktop sharing doesn't stop when the applet is tunneling. Catch t…
  6. @ritzalam

    Merge pull request #2997 from capilkey/fix-2437-regression

    ritzalam committed
    Put the fix for #2437 back in
  7. @ritzalam

    - desktop sharing doesn't stop when the applet is tunneling. Catch t…

    ritzalam committed
    …he exception and stop the applet.
Commits on Feb 3, 2016
  1. @capilkey
  2. @ritzalam

    Merge pull request #2996 from fcecagno/fix-2808

    ritzalam committed
    fix duplicated publish video windows after reconnection #2808
  3. @fcecagno

    fix duplicated publish video windows after reconnection #2808

    fcecagno committed
    The problem was that we were handling the reconnecton succeeded event to start streaming again, but this event is dispatched for every connection, not only for the video connection, and it was causing restream to be called multiple times after the reconnection, eventually duplicating the publish windows; when it occurred, the user was publishing two separate video streams.
    The solution was to use the ConnectedEvent used only by the video connection, which also carries the information if that connection is due to a reconnect.
    It looks like the current solution to restream after a reconnect doesn't work if the user was publishing two cameras at the same time. In that case, I think only the second camera will be published again.
Commits on Feb 2, 2016
  1. @antobinary

    Merge pull request #2991 from OZhurbenko/meteor-whiteboard

    antobinary committed
    Reworked server-side ES6
Commits on Feb 1, 2016
  1. @OZhurbenko
  2. @jfederico
  3. @OZhurbenko

    Corrections

    OZhurbenko committed
  4. @jfederico
Commits on Jan 31, 2016
  1. @ffdixon

    Merge pull request #2994 from ffdixon/minor-fixes

    ffdixon committed
    Minor fixes
  2. @ffdixon
Commits on Jan 30, 2016
  1. @ffdixon
  2. @ffdixon
  3. @OZhurbenko
Commits on Jan 29, 2016
  1. @jfederico
  2. @capilkey
  3. @fcecagno

    fix #2985

    fcecagno committed
    close button on the publish window now closes both remote and local windows
  4. @jfederico
  5. @jfederico
  6. @jfederico
Commits on Jan 28, 2016
  1. @jfederico
  2. @jfederico

    Merge branch 'pedrobmarin-getRecordings' into jfederico-getRecordings

    jfederico committed
    # Conflicts:
    #	bigbluebutton-web/grails-app/controllers/org/bigbluebutton/web/controllers/ApiController.groovy
    #	bigbluebutton-web/src/java/org/bigbluebutton/api/RecordingService.java
  3. @jfederico

    Reformatted files in conflict

    jfederico committed
  4. @jfederico
  5. @jfederico
  6. @jfederico
  7. @jfederico

    bigbluebutton-web: Changed approach for filtering states/recordIDs. t…

    jfederico committed
    …he query is now based on recordID and state parameters instead of filter
Something went wrong with that request. Please try again.